diff --git a/docs/source/create_channel/create_channel_overview.rst b/docs/source/create_channel/create_channel_overview.rst index 154c04011be..5782330e560 100644 --- a/docs/source/create_channel/create_channel_overview.rst +++ b/docs/source/create_channel/create_channel_overview.rst @@ -12,14 +12,9 @@ are the process by which organizations connect with each other and interact. Because of the fundamental role that channels play in the operation and governance of Fabric, we provide a series of tutorials that cover different aspects -of how channels are created. Fabric v2.3 introduces the capability to -create a channel without requiring a system channel, removing an extra -layer of administration from the process. The **Create a channel** -tutorial introduces the new flow. If you don't yet have a network and prefer to use the +of how channels are created. The **Create a channel** +tutorial introduces the channel creation flow. If you don't yet have a network and prefer to use the test network, see **Create a channel using the test network**. -The legacy process for creating a channel based on a system channel continues to be -supported and is described in the Fabric v2.2 -`Create a channel tutorial `_. Each tutorial describes the operational steps that need to be taken by a network administrator to create a channel. For a deeper dive, the :doc:`create_channel_config` tutorial introduces the conceptual aspects of creating a channel, followed by a diff --git a/docs/source/create_channel/create_channel_test_net.md b/docs/source/create_channel/create_channel_test_net.md index 6e713912d32..a6449b9804d 100644 --- a/docs/source/create_channel/create_channel_test_net.md +++ b/docs/source/create_channel/create_channel_test_net.md @@ -2,7 +2,7 @@ Use this tutorial along with the test network to learn how to create a channel genesis block and then create a new application channel that the test network peers can join. Rather than requiring you to set up an orderer, this tutorial leverages the nodes from the Fabric sample test network. Because the test network deploys an ordering service and peers for you, this tutorial focuses solely on the process to create a channel. It is worth noting that the test network includes a `createChannel` subcommand that can be used to create a channel, but this tutorial explains how do it manually, the process that is required when you do not use the test network. -Fabric v2.3 introduces the capability to create a channel without requiring a system channel, removing an extra layer of administration from the process of creating a channel. In this tutorial, we use the [configtxgen](../commands/configtxgen.html) tool to create a channel genesis block and then use the [osnadmin channel](../commands/osnadminchannel.html) command to create the channel. +In this tutorial, we use the [configtxgen](../commands/configtxgen.html) tool to create a channel genesis block and then use the [osnadmin channel](../commands/osnadminchannel.html) command to create the channel. **Note:** - If you are _not_ using the test network, you should follow the instructions for [how to deploy an ordering service](create_channel_participation.html#deploy-a-new-set-of-orderers). diff --git a/docs/source/deployment_guide_overview.rst b/docs/source/deployment_guide_overview.rst index fe7f9acec50..105d6ec76ab 100644 --- a/docs/source/deployment_guide_overview.rst +++ b/docs/source/deployment_guide_overview.rst @@ -37,9 +37,6 @@ In addition to the above, here is a sampling of the decisions you will need to m * **Database type.** Some channels in a network might require all data to be modeled in a way :doc:`couchdb_as_state_database` can understand, while other networks, prioritizing speed, might decide that all peers will use LevelDB. Note that channels should not have peers that use both CouchDB and LevelDB on them, as CouchDB imposes some data restrictions on keys and values. Keys and values that are valid in LevelDB may not be valid in CouchDB. -* **Create a system channel or not.** - Ordering nodes can be bootstrapped with a configuration block for an administrative channel known as the “system channel” (from which application channels can be created), or simply started and joined to application channels as needed. The recommended method is to bootstrap without a configuration block, which is the approach this deployment guide assumes you will take. For more information about creating a system channel genesis block and bootstrapping an ordering node with it, check out `Deploying a production network `_ from the Fabric v2.2 documentation. - * **Channels and private data.** Some networks might decide that :doc:`channels` are the best way to ensure privacy and isolation for certain transactions. Others might decide that fewer channels, supplemented where necessary with :doc:`private-data/private-data` collections, better serves their privacy needs. @@ -194,8 +191,6 @@ Among the parameters in ``orderer.yaml``, there are: For more information about ``orderer.yaml`` and its specific parameters, check out :doc:`deployorderer/ordererchecklist`. -Note: This tutorial assumes that a system channel genesis block will not be used when bootstrapping the orderer. Instead, these nodes (or a subset of them), will be joined to a channel using the process to :doc:`create_channel/create_channel_participation`. For information on how to create an orderer that will be bootstrapped with a system channel genesis block, check out `Deploy the ordering service `_ from the Fabric v2.2 documentation. - .. toctree:: :maxdepth: 1 :caption: Deploying a production ordering node diff --git a/docs/source/deployorderer/ordererchecklist.md b/docs/source/deployorderer/ordererchecklist.md index c342a4af95d..780a8667522 100644 --- a/docs/source/deployorderer/ordererchecklist.md +++ b/docs/source/deployorderer/ordererchecklist.md @@ -132,32 +132,6 @@ In general, these four parameters would only need to be configured if you want t * **`ServerCertificate`** * **`ServerPrivateKey`** -## General.BoostrapMethod - -``` -# Bootstrap method: The method by which to obtain the bootstrap block -# system channel is specified. The option can be one of: -# "file" - path to a file containing the genesis block or config block of system channel -# "none" - allows an orderer to start without a system channel configuration -BootstrapMethod: none -``` -**`BootstrapMethod`**: Since Fabric v3.0 system channel is no longer supported, thus override this value to `none` and then ensure that [`ChannelParticipation.Enabled`](#channelparticipation) is set to `true`, otherwise you will get an error when you attempt to start the node. - -## General.BoostrapFile - -``` -# Bootstrap file: The file containing the bootstrap block to use when -# initializing the orderer system channel and BootstrapMethod is set to -# "file". The bootstrap file can be the genesis block, and it can also be -# a config block for late bootstrap of some consensus methods like Raft. -# Generate a genesis block by updating $FABRIC_CFG_PATH/configtx.yaml and -# using configtxgen command with "-outputBlock" option. -# Defaults to file "genesisblock" (in $FABRIC_CFG_PATH directory) if not specified. -BootstrapFile: -``` - -**`BoostrapFile`**: Since Fabric v3.0 the system channel is no longer supported, so this value will not be used, and can therefore be left blank. - ## General.LocalMSPDir ``` @@ -349,13 +323,14 @@ Admin: ``` ChannelParticipation: # Channel participation API is enabled. - Enabled: false + Enabled: true # The maximum size of the request body when joining a channel. MaxRequestBodySize: 1 MB ``` -* **`Enabled`**: If you are bootstrapping the ordering node with a system channel genesis block, this value can be set to either `true` or `false` (setting the value to `true` allows you to list channels and to migrate away from the system channel in the future). If you are **not** bootstrapping the ordering node with a system channel genesis block, this value must be set to `true` and the [`General.BoostrapMethod`](#general-boostrapmethod) should be set to `none`. +* **`Enabled`**: Since system channel is no longer supported, this value must be `true` so that you can join ordering service nodes to a channel. + * **`MaxRequestBodySize`**: (default value should not be overridden) This value controls the maximum size a configuration block can be and be accepted by this ordering node. Most configuration blocks are smaller than 1 MB, but if for some reason a configuration block is too large to be accept, bring down the node, increase this value, and restart the node. ## Consensus.* diff --git a/docs/source/deployorderer/ordererdeploy.md b/docs/source/deployorderer/ordererdeploy.md index 79e725654f6..3eeef5d3b38 100644 --- a/docs/source/deployorderer/ordererdeploy.md +++ b/docs/source/deployorderer/ordererdeploy.md @@ -103,7 +103,6 @@ At a minimum, you need to configure the following parameters: - `General.TLS.PrivateKey ` - Ordering node private key from TLS CA. - `General.TLS.Certificate ` - Ordering node signed certificate (public key) from the TLS CA. - `General.TLS.RootCAS` - This value should be unset. -- `General.BoostrapMethod:none` - This allows the orderer to start without needing a system channel configuration block (system channel is no longer supported since Fabric v3.0). - `General.LocalMSPDir` - Path to the ordering node MSP folder. - `General.LocalMSPID` - MSP ID of the ordering organization as specified in the channel configuration. - `FileLedger.Location` - Location on the file system to the ledgers of the channels this orderer will be servicing. diff --git a/docs/source/glossary.rst b/docs/source/glossary.rst index e3c513bf65f..8f7df857052 100644 --- a/docs/source/glossary.rst +++ b/docs/source/glossary.rst @@ -182,9 +182,7 @@ Consenter set ------------- In a Raft ordering service, these are the ordering nodes actively participating -in the consensus mechanism on a channel. If other ordering nodes exist on the -system channel, but are not a part of a channel, they are not part of that -channel's consenter set. +in the consensus mechanism on a channel. .. _Consortium: @@ -588,23 +586,6 @@ State Database World state data is stored in a state database for efficient reads and queries from chaincode. Supported databases include levelDB and couchDB. -.. _System-Chain: - -System Chain ------------- - -Contains a configuration block defining the network at a system level. The -system chain lives within the ordering service, and similar to a channel, has -an initial configuration containing information such as: MSP information, policies, -and configuration details. Any change to the overall network (e.g. a new org -joining or a new ordering node being added) will result in a new configuration block -being added to the system chain. - -The system chain can be thought of as the common binding for a channel or group -of channels. For instance, a collection of financial institutions may form a -consortium (represented through the system chain), and then proceed to create -channels relative to their aligned and varying business agendas. - .. _Transaction: Transaction diff --git a/docs/source/msp.rst b/docs/source/msp.rst index 18acf125354..32d3193fa54 100644 --- a/docs/source/msp.rst +++ b/docs/source/msp.rst @@ -191,8 +191,7 @@ administrator to their bearer, provided that they possess the client or admin OU Adding MSPs to channels ----------------------- -For information about how to add MSPs to a channel (including the decision of -whether to bootstrap ordering nodes with a system channel genesis block), check +For information about how to add MSPs to a channel, check out :doc:`create_channel/create_channel_overview`. Best practices diff --git a/orderer/common/cluster/testdata/blockverification/orderer.yaml b/orderer/common/cluster/testdata/blockverification/orderer.yaml index e6d77b70752..063f7e67e4c 100644 --- a/orderer/common/cluster/testdata/blockverification/orderer.yaml +++ b/orderer/common/cluster/testdata/blockverification/orderer.yaml @@ -127,30 +127,13 @@ General: # it switches to a new orderer as a source of blocks. ReplicationPolicy: - # Bootstrap method: The method by which to obtain the bootstrap block - # system channel is specified. The option can be one of: - # "file" - path to a file containing the genesis block or config block of system channel - # "none" - allows an orderer to start without a system channel configuration - BootstrapMethod: none - - # Bootstrap file: The file containing the bootstrap block to use when - # initializing the orderer system channel and BootstrapMethod is set to - # "file". The bootstrap file can be the genesis block, and it can also be - # a config block for late bootstrap of some consensus methods like Raft. - # Generate a genesis block by updating $FABRIC_CFG_PATH/configtx.yaml and - # using configtxgen command with "-outputBlock" option. - # Defaults to file "genesisblock" (in $FABRIC_CFG_PATH directory) if not specified. - BootstrapFile: - # LocalMSPDir is where to find the private crypto material needed by the # orderer. It is set relative here as a default for dev environments but # should be changed to the real location in production. LocalMSPDir: msp # LocalMSPID is the identity to register the local MSP material with the MSP - # manager. IMPORTANT: The local MSP ID of an orderer needs to match the MSP - # ID of one of the organizations defined in the orderer system channel's - # /Channel/Orderer configuration. The sample organization defined in the + # manager. The sample organization defined in the # sample configuration provided has an MSP ID of "SampleOrg". LocalMSPID: SampleOrg diff --git a/sampleconfig/orderer.yaml b/sampleconfig/orderer.yaml index e6d77b70752..063f7e67e4c 100644 --- a/sampleconfig/orderer.yaml +++ b/sampleconfig/orderer.yaml @@ -127,30 +127,13 @@ General: # it switches to a new orderer as a source of blocks. ReplicationPolicy: - # Bootstrap method: The method by which to obtain the bootstrap block - # system channel is specified. The option can be one of: - # "file" - path to a file containing the genesis block or config block of system channel - # "none" - allows an orderer to start without a system channel configuration - BootstrapMethod: none - - # Bootstrap file: The file containing the bootstrap block to use when - # initializing the orderer system channel and BootstrapMethod is set to - # "file". The bootstrap file can be the genesis block, and it can also be - # a config block for late bootstrap of some consensus methods like Raft. - # Generate a genesis block by updating $FABRIC_CFG_PATH/configtx.yaml and - # using configtxgen command with "-outputBlock" option. - # Defaults to file "genesisblock" (in $FABRIC_CFG_PATH directory) if not specified. - BootstrapFile: - # LocalMSPDir is where to find the private crypto material needed by the # orderer. It is set relative here as a default for dev environments but # should be changed to the real location in production. LocalMSPDir: msp # LocalMSPID is the identity to register the local MSP material with the MSP - # manager. IMPORTANT: The local MSP ID of an orderer needs to match the MSP - # ID of one of the organizations defined in the orderer system channel's - # /Channel/Orderer configuration. The sample organization defined in the + # manager. The sample organization defined in the # sample configuration provided has an MSP ID of "SampleOrg". LocalMSPID: SampleOrg