FAB-15754 Deprecate solo orderer

Jason Yellick · Jason Yellick · commit 1c18f833fdb3 · 2019-11-12T14:29:14.000-05:00
This CR removes many Solo references from the docs, it notably does not
touch the chaincode tutorial, or the first network tutorial, as these
are in flux.

It also adds a warning which is emitted when starting a channel with the
Solo consensus type, and removes the default 'SampleInsecureSolo'
profile from configtxgen.

Signed-off-by: Jason Yellick &lt;jyellick@us.ibm.com&gt;
Change-Id: Ide57e8ca4109e7d31d7f363dc088205a6b5683b5
diff --git a/cmd/configtxgen/main.go b/cmd/configtxgen/main.go
@@ -213,7 +213,7 @@ func main() {
 	flag.StringVar(&channelID, "channelID", "", "The channel ID to use in the configtx")
 	flag.StringVar(&outputChannelCreateTx, "outputCreateChannelTx", "", "The path to write a channel creation configtx to (if set)")
 	flag.StringVar(&channelCreateTxBaseProfile, "channelCreateTxBaseProfile", "", "Specifies a profile to consider as the orderer system channel current state to allow modification of non-application parameters during channel create tx generation. Only valid in conjunction with 'outputCreateChannelTx'.")
-	flag.StringVar(&profile, "profile", genesisconfig.SampleInsecureSoloProfile, "The profile from configtx.yaml to use for generation.")
+	flag.StringVar(&profile, "profile", "", "The profile from configtx.yaml to use for generation.")
 	flag.StringVar(&configPath, "configPath", "", "The path containing the configuration to use (if set)")
 	flag.StringVar(&inspectBlock, "inspectBlock", "", "Prints the configuration contained in the block at the specified path")
 	flag.StringVar(&inspectChannelCreateTx, "inspectChannelCreateTx", "", "Prints the configuration contained in the transaction at the specified path")
@@ -258,6 +258,10 @@ func main() {
 	factory.InitFactories(nil)
 	var profileConfig *genesisconfig.Profile
 	if outputBlock != "" || outputChannelCreateTx != "" || outputAnchorPeersUpdate != "" {
+		if profile == "" {
+			logger.Fatalf("The '-profile' is required when '-outputBlock', '-outputChannelCreateTx', or '-outputAnchorPeersUpdate' is specified")
+		}
+
 		if configPath != "" {
 			profileConfig = genesisconfig.Load(profile, configPath)
 		} else {
diff --git a/docs/source/Fabric-FAQ.rst b/docs/source/Fabric-FAQ.rst
@@ -243,12 +243,12 @@ Ordering Service
 :Answer:
   A consensus plugin needs to implement the ``Consenter`` and ``Chain``
   interfaces defined in the `consensus package`_. There are two plugins built
-  against these interfaces already: solo_ and kafka_. You can study them to take
+  against these interfaces already: raft_ and kafka_. You can study them to take
   cues for your own implementation. The ordering service code can be found under
   the `orderer package`_.
 
 .. _consensus package: https://github.com/hyperledger/fabric/blob/master/orderer/consensus/consensus.go
-.. _solo: https://github.com/hyperledger/fabric/tree/master/orderer/consensus/solo
+.. _raft: https://github.com/hyperledger/fabric/tree/master/orderer/consensus/etcdraft
 .. _kafka: https://github.com/hyperledger/fabric/tree/master/orderer/consensus/kafka
 .. _orderer package: https://github.com/hyperledger/fabric/tree/master/orderer
 
@@ -270,7 +270,8 @@ Solo
 
 :Answer:
   Solo is not intended for production.  It is not, and will never be, fault
-  tolerant.
+  tolerant.  It has been deprecated in favor of Raft and may be removed in a
+  future release.
 
 Kafka
 ~~~~~
diff --git a/docs/source/blockchain.rst b/docs/source/blockchain.rst
@@ -216,7 +216,7 @@ that are highly structured in their relationships to those that are more
 peer-to-peer.
 
 We’ll learn more about the Hyperledger Fabric consensus mechanisms, which
-currently include SOLO, Kafka, and Raft.
+currently include Kafka, and Raft.
 
 Where can I learn more?
 -----------------------
diff --git a/docs/source/capability_requirements.rst b/docs/source/capability_requirements.rst
@@ -66,7 +66,7 @@ it for your network. For example:
 
 .. code:: bash
 
-    SampleSingleMSPSoloV1_1:
+    SampleSingleMSPRaftV1_1:
         Capabilities:
             <<: *GlobalCapabilities
         Orderer:
diff --git a/docs/source/commands/configtxgen.md b/docs/source/commands/configtxgen.md
@@ -33,7 +33,7 @@ Usage of configtxgen:
   -printOrg string
     	Prints the definition of an organization as JSON. (useful for adding an org to a channel manually)
   -profile string
-    	The profile from configtx.yaml to use for generation. (default "SampleInsecureSolo")
+    	The profile from configtx.yaml to use for generation.
   -version
     	Show version information
 ```
@@ -43,10 +43,10 @@ Usage of configtxgen:
 ### Output a genesis block
 
 Write a genesis block to `genesis_block.pb` for channel `orderer-system-channel`
-for profile `SampleSingleMSPSoloV1_1`.
+for profile `SampleSingleMSPRaftV1_1`.
 
 ```
-configtxgen -outputBlock genesis_block.pb -profile SampleSingleMSPSoloV1_1 -channelID orderer-system-channel
+configtxgen -outputBlock genesis_block.pb -profile SampleSingleMSPRaftV1_1 -channelID orderer-system-channel
 ```
 
 ### Output a channel creation tx
@@ -102,26 +102,6 @@ The `configtxgen` tool's output is largely controlled by the content of
 `configtx.yaml`.  This file is searched for at `FABRIC_CFG_PATH` and must be
 present for `configtxgen` to operate.
 
-This configuration file may be edited, or, individual properties may be
-overridden by setting environment variables, such as
-`CONFIGTX_ORDERER_ORDERERTYPE=kafka`.
-
-For many `configtxgen` operations, a profile name must be supplied.  Profiles
-are a way to express multiple similar configurations in a single file.  For
-instance, one profile might define a channel with 3 orgs, and another might
-define one with 4 orgs.  To accomplish this without the length of the file
-becoming burdensome, `configtx.yaml` depends on the standard YAML feature of
-anchors and references.  Base parts of the configuration are tagged with an
-anchor like `&OrdererDefaults` and then merged into a profile with a reference
-like `<<: *OrdererDefaults`.  Note, when `configtxgen` is operating under a
-profile, environment variable overrides do not need to include the profile
-prefix and may be referenced relative to the root element of the profile.  For
-instance, do not specify
-`CONFIGTX_PROFILE_SAMPLEINSECURESOLO_ORDERER_ORDERERTYPE`,
-instead simply omit the profile specifics and use the `CONFIGTX` prefix
-followed by the elements relative to the profile name such as
-`CONFIGTX_ORDERER_ORDERERTYPE`.
-
 Refer to the sample `configtx.yaml` shipped with Fabric for all possible
 configuration options.  You may find this file in the `config` directory of
 the release artifacts tar, or you may find it under the `sampleconfig` folder
diff --git a/docs/source/glossary.rst b/docs/source/glossary.rst
@@ -440,11 +440,11 @@ Ordering Service
 ----------------
 
 Also known as **orderer**. A defined collective of nodes that orders transactions into a block
-and then distributes blocks to connected peers for validation and commit. The ordering service 
-exists independent of the peer processes and orders transactions on a first-come-first-serve basis 
-for all channels on the network.  It is designed to support pluggable implementations beyond the 
-out-of-the-box SOLO, Kafka, and Raft varieties. It is a common binding for the overall network;
-it contains the cryptographic identity material tied to each Member_.
+and then distributes blocks to connected peers for validation and commit. The ordering service
+exists independent of the peer processes and orders transactions on a first-come-first-serve basis
+for all channels on the network.  It is designed to support pluggable implementations beyond the
+out-of-the-box Kafka and Raft varieties. It is a common binding for the overall network; it
+contains the cryptographic identity material tied to each Member_.
 
 .. _Organization:
 
diff --git a/docs/source/orderer/ordering_service.md b/docs/source/orderer/ordering_service.md
@@ -203,17 +203,6 @@ between ordering service nodes.
 For information about how to stand up an ordering node (regardless of the
 implementation the node will be used in), check out [our documentation on standing up an ordering node](../orderer_deploy.html).
 
-* **Solo**
-
-  The Solo implementation of the ordering service is aptly named: it features
-  only a single ordering node. As a result, it is not, and never will be, fault
-  tolerant. For that reason, Solo implementations cannot be considered for
-  production, but they are a good choice for testing applications and smart
-  contracts, or for creating proofs of concept. However, if you ever want to
-  extend this PoC network into production, you might want to start with a single
-  node Raft cluster, as it may be reconfigured to add additional nodes.
-
-
 * **Raft**
 
   New as of v1.4.1, Raft is a crash fault tolerant (CFT) ordering service
@@ -233,19 +222,12 @@ implementation the node will be used in), check out [our documentation on standi
   available since Fabric v1.0, but many users may find the additional
   administrative overhead of managing a Kafka cluster intimidating or undesirable.
 
-## Solo
-
-As stated above, a Solo ordering service is a good choice when developing test,
-development, or proofs-of-concept networks. For that reason, it is the default
-ordering service deployed in our [Build your first network tutorial](../build_network.html)),
-as, from the perspective of other network components, a Solo ordering service
-processes transactions identically to the more elaborate Kafka and Raft
-implementations while saving on the administrative overhead of maintaining and
-upgrading multiple nodes and clusters. Because a Solo ordering service is not
-crash-fault tolerant, it should never be considered a viable alternative for a
-production blockchain network. For networks which wish to start with only a
-single ordering node but might wish to grow in the future, a single node Raft
-cluster is a better option.
+* **Solo**
+
+  The Solo implementation of the ordering service is intended for test only and
+  consists only of a single ordering node.  It has been deprecated and may be
+  removed entirely in a future release.  Existing users of Solo should move to
+  a single node Raft network for equivalent function.
 
 ## Raft
 
diff --git a/docs/source/whatsnew.rst b/docs/source/whatsnew.rst
@@ -124,8 +124,7 @@ across the world to contribute nodes to a decentralized ordering service.
 
 * :doc:`orderer/ordering_service`:
   Describes the role of an ordering service in Fabric and an overview of the
-  three ordering service implementations currently available: Solo, Kafka, and
-  Raft.
+  two ordering service implementations currently available: Kafka and Raft.
 
 * :doc:`raft_configuration`:
   Shows the configuration parameters and considerations when deploying a Raft
diff --git a/docs/wrappers/configtxgen_postscript.md b/docs/wrappers/configtxgen_postscript.md
@@ -3,10 +3,10 @@
 ### Output a genesis block
 
 Write a genesis block to `genesis_block.pb` for channel `orderer-system-channel`
-for profile `SampleSingleMSPSoloV1_1`.
+for profile `SampleSingleMSPRaftV1_1`.
 
 ```
-configtxgen -outputBlock genesis_block.pb -profile SampleSingleMSPSoloV1_1 -channelID orderer-system-channel
+configtxgen -outputBlock genesis_block.pb -profile SampleSingleMSPRaftV1_1 -channelID orderer-system-channel
 ```
 
 ### Output a channel creation tx
@@ -62,26 +62,6 @@ The `configtxgen` tool's output is largely controlled by the content of
 `configtx.yaml`.  This file is searched for at `FABRIC_CFG_PATH` and must be
 present for `configtxgen` to operate.
 
-This configuration file may be edited, or, individual properties may be
-overridden by setting environment variables, such as
-`CONFIGTX_ORDERER_ORDERERTYPE=kafka`.
-
-For many `configtxgen` operations, a profile name must be supplied.  Profiles
-are a way to express multiple similar configurations in a single file.  For
-instance, one profile might define a channel with 3 orgs, and another might
-define one with 4 orgs.  To accomplish this without the length of the file
-becoming burdensome, `configtx.yaml` depends on the standard YAML feature of
-anchors and references.  Base parts of the configuration are tagged with an
-anchor like `&OrdererDefaults` and then merged into a profile with a reference
-like `<<: *OrdererDefaults`.  Note, when `configtxgen` is operating under a
-profile, environment variable overrides do not need to include the profile
-prefix and may be referenced relative to the root element of the profile.  For
-instance, do not specify
-`CONFIGTX_PROFILE_SAMPLEINSECURESOLO_ORDERER_ORDERERTYPE`,
-instead simply omit the profile specifics and use the `CONFIGTX` prefix
-followed by the elements relative to the profile name such as
-`CONFIGTX_ORDERER_ORDERERTYPE`.
-
 Refer to the sample `configtx.yaml` shipped with Fabric for all possible
 configuration options.  You may find this file in the `config` directory of
 the release artifacts tar, or you may find it under the `sampleconfig` folder
diff --git a/orderer/consensus/solo/consensus.go b/orderer/consensus/solo/consensus.go
@@ -40,6 +40,7 @@ func New() consensus.Consenter {
 }
 
 func (solo *consenter) HandleChain(support consensus.ConsenterSupport, metadata *cb.Metadata) (consensus.Chain, error) {
+	logger.Warningf("Use of the Solo orderer is deprecated and remains only for use in test environments but may be removed in the future.")
 	return newChain(support), nil
 }
 

Original file line number	Diff line number	Diff line change
`@@ -40,6 +40,7 @@ func New() consensus.Consenter {`
`40`	`40`	`}`
`41`	`41`
`42`	`42`	`func (solo consenter) HandleChain(support consensus.ConsenterSupport, metadata cb.Metadata) (consensus.Chain, error) {`
	`43`	`+ logger.Warningf("Use of the Solo orderer is deprecated and remains only for use in test environments but may be removed in the future.")`
`43`	`44`	`return newChain(support), nil`
`44`	`45`	`}`
`45`	`46`