Merge pull request #578 from hyperledger-labs/release-2.0

merge release-2.0 to master

docs/source/CONTRIBUTING.rst

@@ -291,7 +291,7 @@ hours (3 days), it will be flagged to the #fabric-pr-review channel daily until
 it receives a review comment(s).
 
 This policy applies to all official Fabric projects (fabric, fabric-ca,
-fabric-samples, fabric-test, fabric-sdk-node, fabric-sdk-java,
+fabric-samples, fabric-test, fabric-sdk-node, fabric-sdk-java, fabric-gateway-java,
 fabric-chaincode-node, fabric-chaincode-java, fabric-chaincode-evm,
 fabric-baseimage, and fabric-amcl).
 

docs/source/Fabric-FAQ.rst

@@ -242,15 +242,13 @@ 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: raft_ and kafka_. You can study them to take
-  cues for your own implementation. The ordering service code can be found under
+  interfaces defined in the `consensus package`_. There is a plugin built
+  against raft_ . You can study it to learn more 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
-.. _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
+.. _consensus package: https://github.com/hyperledger/fabric/blob/release-2.0/orderer/consensus/consensus.go
+.. _raft: https://github.com/hyperledger/fabric/tree/release-2.0/orderer/consensus/etcdraft
+.. _orderer package: https://github.com/hyperledger/fabric/tree/release-2.0/orderer
 
 ..
 
@@ -262,78 +260,6 @@ Ordering Service
   This falls under reconfiguring the network. Please consult the topic on
   :doc:`commands/configtxlator`.
 
-Solo
-~~~~
-
-:Question:
-  **How can I deploy Solo in production?**
-
-:Answer:
-  Solo is not intended for production.  It is not, and will never be, fault
-  tolerant.  It has been deprecated in favor of Raft and may be removed in a
-  future release.
-
-Kafka
-~~~~~
-
-:Question:
-  **How do I remove a node from the ordering service?**
-
-:Answer:
-  This is a two step-process:
-
-  1. Add the node's certificate to the relevant orderer's MSP CRL to prevent peers/clients from connecting to it.
-  2. Prevent the node from connecting to the Kafka cluster by leveraging standard Kafka access control measures such as TLS CRLs, or firewalling.
-
-..
-
-:Question:
-  **I have never deployed a Kafka/ZK cluster before, and I want to use the
-  Kafka-based ordering service. How do I proceed?**
-
-:Answer:
-  The Hyperledger Fabric documentation assumes the reader generally has the
-  operational expertise to setup, configure, and manage a Kafka cluster
-  (see :ref:`kafka-caveat`). If you insist on proceeding without such expertise,
-  you should complete, *at a minimum*, the first 6 steps of the
-  `Kafka Quickstart guide`_ before experimenting with the Kafka-based ordering
-  service. You can also consult `this sample configuration file`_ for a brief
-  explanation of the sensible defaults for Kafka/ZooKeeper.
-
-.. _Kafka Quickstart guide: https://kafka.apache.org/quickstart
-.. _this sample configuration file: https://github.com/hyperledger/fabric/blob/release-1.1/bddtests/dc-orderer-kafka.yml
-
-..
-
-:Question:
-  **Where can I find a Docker composition for a network that uses the
-  Kafka-based ordering service?**
-
-:Answer:
-  Consult `the end-to-end CLI example`_.
-
-.. _the end-to-end CLI example: https://github.com/hyperledger/fabric/blob/release-1.3/examples/e2e_cli/docker-compose-e2e.yaml
-
-..
-
-:Question:
-  **Why is there a ZooKeeper dependency in the Kafka-based ordering service?**
-
-:Answer:
-  Kafka uses it internally for coordination between its brokers.
-
-..
-
-:Question:
-  **I'm trying to follow the BYFN example and get a "service unavailable" error,
-  what should I do?**
-
-:Answer:
-  Check the ordering service's logs. A "Rejecting deliver request because of
-  consenter error" log message is usually indicative of a connection problem
-  with the Kafka cluster. Ensure that the Kafka cluster is set up properly, and
-  is reachable by the ordering service's nodes.
-
 BFT
 ~~~
 

docs/source/access_control.md

@@ -23,7 +23,7 @@ exercised.
 
 Application developers need to be aware of these resources and the default
 policies associated with them. The complete list of these resources are found in
-`configtx.yaml`. You can look at a [sample `configtx.yaml` file here](http://github.com/hyperledger/fabric/blob/release-1.2/sampleconfig/configtx.yaml).
+`configtx.yaml`. You can look at a [sample `configtx.yaml` file here](http://github.com/hyperledger/fabric/blob/release-2.0/sampleconfig/configtx.yaml).
 
 The resources named in `configtx.yaml` is an exhaustive list of all internal resources
 currently defined by Fabric. The loose convention adopted there is `<component>/<resource>`.
@@ -108,7 +108,7 @@ access control in the channel configuration of an existing channel.
 ## How ACLs are formatted in `configtx.yaml`
 
 ACLs are formatted as a key-value pair consisting of a resource function name
-followed by a string. To see what this looks like, reference this [sample configtx.yaml file](https://github.com/hyperledger/fabric/blob/release-1.2/sampleconfig/configtx.yaml).
+followed by a string. To see what this looks like, reference this [sample configtx.yaml file](https://github.com/hyperledger/fabric/blob/release-2.0/sampleconfig/configtx.yaml).
 
 Two excerpts from this sample:
 
@@ -281,21 +281,5 @@ whatever you want them to be. As a result, it's important to keep track of these
 policies to ensure that the ACLs for peer proposals are not impossible to satisfy
 (unless that is the intention).
 
-#### Migration considerations for customers using the experimental ACL feature
-
-Previously, the management of access control lists was done in an `isolated_data`
-section of the channel creation transaction and updated via `PEER_RESOURCE_UPDATE`
-transactions. Originally, it was thought that the `resources` tree would handle the
-update of several functions that, ultimately, were handled in other ways, so
-maintaining a separate parallel peer configuration tree was judged to be unnecessary.
-
-Migration for customers using the experimental resources tree in v1.1 is possible.
-Because the official v1.2 release does not support the old ACL methods, the network
-operators should shut down all their peers.  Then, they should upgrade them to v1.2,
-submit a channel reconfiguration transaction which enables the v1.2 capability and
-sets the desired ACLs, and then finally restart the upgraded peers.  The restarted
-peers will immediately consume the new channel configuration and enforce the ACLs as
-desired.
-
 <!--- Licensed under Creative Commons Attribution 4.0 International License
 https://creativecommons.org/licenses/by/4.0/ -->