Add release notes for v2.2

Signed-off-by: David Enyeart <enyeart@us.ibm.com>

docs/source/whatsnew.rst

@@ -216,6 +216,7 @@ announced with the new Fabric v2.0 release, and the changes introduced in v2.1.
 * `Fabric v2.0.1 release notes <https://github.com/hyperledger/fabric/releases/tag/v2.0.1>`_.
 * `Fabric v2.1.0 release notes <https://github.com/hyperledger/fabric/releases/tag/v2.1.0>`_.
 * `Fabric v2.1.1 release notes <https://github.com/hyperledger/fabric/releases/tag/v2.1.1>`_.
+* `Fabric v2.2.0 release notes <https://github.com/hyperledger/fabric/releases/tag/v2.2.0>`_.
 
 .. Licensed under Creative Commons Attribution 4.0 International License
    https://creativecommons.org/licenses/by/4.0/

release_notes/v2.2.0.md

@@ -1,26 +1,232 @@
-v2.2.0 Release Notes - July XX, 2020
-====================================
+v2.2.0 Release Notes - July 9, 2020
+===================================
 
 What's New in Hyperledger Fabric v2.2
 -------------------------------------
 
+**FAB-13460: Add Support for TLS 1.3**
+
+TLS 1.3 is now supported and will be utilized automatically if client supports TLS 1.3.
+
+**FAB-17401: Add function to query the details of the approved chaincode definition**
+
+Add support to query an organization's approved chaincode definition from its peer.
+The function is available by using peer CLI command `peer lifecycle chaincode queryapproved`.
+
 
 Fixes
 -----
 
+**Return Error From PKCS11 CreateSession**
+
+The prior implementation of BCCSP performed a fatal
+logging function in the event it could not open a session
+with the HSM.  It was possible for the fatal log to occur when an expected error
+occurred, i.e., the HSM had reached its maximum session handles.
+Instead of issuing a fatal log call, an error is returned so that
+the error can be properly handled.
+
+**FAB-17819: Discovery returns user friendly errors**
+
+Service discovery endorsement service error message "cannot satisfy any principal combination" is
+improved to return a more specific message, either "no peer combination can satisfy the endorsement policy"
+or "required chaincodes are not installed on sufficient peers".
+
+**FAB-17774: Support orderer restart without system channel genesis block**
+
+When BootstrapMethod was set to 'file', the system channel genesis block
+was required to be passed for every orderer service start. The system
+channel genesis block is now only required for the initial orderer start.
+
+**FAB-17844: External builder fails to copy symlinks from build output into persistent directory**
+
+Previously, the external builder code did not check for symlinks in build output when copying them.
+This resulted in the resolved files being copied as files instead of symlinks. The external builder
+now copies them as symlinks instead of copying them as files into the destination directory.
+
+**Errors should be checked when orderer gRPC server is serving requests**
+
+gRPC errors are now checked when servicing the orderer atomic broadcast gRPC service.
+
+**FAB-17900: Fix environment variable override bug**
+
+Integer config values for peer and orderer could not be overridden with environment variables.
+
+**FAB-17951: Fetch correct node id for orderer consenter validation**
+
+Config update validator may incorrectly reject updates if some nodes are inactive.
+
+**FAB-17875: Fix ordering service node leader election failure**
+
+Previously with Raft consensus, when one ordering service node was deleted
+from a channel and rejoined later, it would be assigned a new Raft id.
+However, in some cases the ordering service node still used the old Raft
+id. Other ordering service nodes including the leader are using the latest view and believe
+that the rejoined node would use a new Raft id.  This may result in leader election failure and no new
+transactions would be accepted. The fix ensures the correct Raft id is used after tracking the latest config block.
+
+**Private data performance optimization: purge transient store in background**
+
+Private data performance is improved by purging entries present in the transient store in the background.
+
+**FAB-17933: Fix cache update logic for installed chaincode info when an empty or uninstalled package ID is specified**
+
+Previous cache update logic for install chaincode info did not work properly when an empty or uninstalled package ID was specified.
+
+**FAB-17539: Always remember gossip anchor peers in membership**
+
+Gossip removes a peer from its membership cache if no new heartbeats are received from the peer within a timely manner.
+If a network partition persists for too long, peers of different organizations never re-establish communication because all membership is purged.
+With the fix, anchor peers are no longer removed from the membership cache even if they are offline.
+Therefore, after the network partition is healed, peers among different organizations can reestablish communication as long as anchor peers are reachable.
+
+**Note: Fixes included in v2.1.1 release notes are also included in v2.2.**
 
 Changes
 -------
 
-- **FAB-17917: Change default CouchDB maxRetriesOnStartup property from 12 to 10**
+**FAB-17786: upgrade_dbs peer command now drops state CouchDB databases**
+
+Previously the upgrade_dbs command did not automatically drop state CouchDB
+databases and therefore a separate step was required to drop CouchDB data
+when upgrading to v2.x. upgrade_dbs command now automatically drops
+state CouchDB databases. CouchDB state database will get rebuilt on the first
+peer start after the upgrade to v2.x. CouchDB database service
+must be available when running upgrade_dbs command. Similarly,
+rebuild-dbs also drops state CouchDB data now, so that state database
+can be rebuilt on the next peer start.
+
+**FAB-17869: Allow TLS CAs with overlapping issuers**
+
+The client root TLS CA certificate pool construction didn't allow different issuers
+with the same subject name to exist in the CA cert pool. Different issuers with
+the same subject name are now allowed.
+
+**Fabric CouchDB tests have been updated from CouchDB 2.3.1 to CouchDB 3.1.0**
 
-  The time between retries doubles after each attempt.
-  Therefore if CouchDB is not yet started, the peer start will now retry
-  for about 2 minutes rather than 16 minutes before retries are exhausted.
+Support is added for CouchDB 3.1.0 as the recommended and tested version of CouchDB.
+If prior versions are utilized, a Warning will appear in peer log.
+Note that CouchDB 3.1.0 requires that an admin username and password be set,
+while this was optional in CouchDB v2.x. See the
+[Fabric CouchDB documentation](https://hyperledger-fabric.readthedocs.io/en/release-2.2/couchdb_as_state_database.html#couchdb-configuration)
+for configuration details.
+Also note that CouchDB 3.1.0 default max_document_size is reduced to 8MB. Set a higher value if needed in your environment.
+Finally, the fabric-couchdb docker image will not be updated to v3.1.0 and will no longer be updated, maintained, or published.
+Users can utilize the official CouchDB docker image maintained by the Apache CouchDB project instead.
+
+**FAB-17917: Peer CouchDB default `maxRetriesOnStartup` property has been updated**
+
+Peer property `peer.ledger.state.couchDBConfig.maxRetriesOnStartup` default has
+changed from 12 to 10. The time between retries doubles after each attempt.
+Therefore if CouchDB is not yet started, the peer start will now retry
+for about 2 minutes rather than 16 minutes before retries are exhausted.
+
+**FAB-16435: Peer gossip defaults have been updated**
+
+Block dissemination via gossip may be removed in a future release,
+since it is more straightforward for peers to simply pull blocks from ordering service.
+The gossip defaults have been updated to prepare users for this possible change, so that peers by default
+pull blocks from ordering service, do not use leader election, and do not use block transfer across peers.
+Additionally, two block cache default sizes have been lowered to reduce the memory
+used by a peer when it has joined many channels.
+The new defaults are as follows:
+```
+peer.gossip.orgLeader: true
+peer.gossip.useLeaderElection: false
+peer.gossip.state.enabled: false
+peer.gossip.maxBlockCountToStore: 10
+peer.gossip.state.blockBufferSize: 20
+```
+Default configuration values are included in the peer docker image, therefore if you apply
+the new peer image the new defaults will be effective unless you specifically override them
+in your configuration.
+
+**Build Your First Network sample and tutorial has been removed**
+
+Users are recommended to use the [test network](https://hyperledger-fabric.readthedocs.io/en/release-2.2/test_network.html) introduced in v2.0 instead,
+and to review the new [deployment guides](https://hyperledger-fabric.readthedocs.io/en/release-2.2/deployment_guide_overview.html).
+
+**FAB-18028: Replace `environmentWhiteList` peer property with `propagateEnvironment`**
+
+Peer configuration property `peer.chaincode.externalBuilders.environmentWhiteList` has been replaced with `peer.chaincode.externalBuilders.propagateEnvironment`.
+`environmentWhiteList` continues to work but is deprecated.
 
 
 Dependency updates
 ------------------
+Fabric project now uses Go modules for vendoring code dependencies.
+
+Bump Go gRPC to 1.29.1.
+
+Bump Go to 1.14.4.
+
+Bump Alpine to 3.12 in Fabric images.
+
+CouchDB 3.1.0 is now the tested CouchDB version.
+
+
+Deprecations
+------------
+
+**FAB-15754: The 'Solo' consensus type is deprecated.**
+
+The 'Solo' consensus type has always been marked non-production and should be in
+use only in test environments, however for compatibility it is still available,
+but may be removed entirely in a future release.
+
+**FAB-16408: The 'Kafka' consensus type is deprecated.**
+
+The 'Raft' consensus type was introduced in v1.4.1 and has become the preferred
+production consensus type.  There is a documented and tested migration path from
+Kafka to Raft, and existing users should migrate to the newer Raft consensus type.
+For compatibility with existing deployments, Kafka is still supported,
+but may be removed entirely in a future release.
+Additionally, the fabric-kafka and fabric-zookeeper docker images are no longer updated, maintained, or published.
+
+**FAB-7559: Support for specifying orderer endpoints at the global level in channel configuration is deprecated.**
+
+Utilize the new 'OrdererEndpoints' stanza within the channel configuration of an organization instead.
+Configuring orderer endpoints at the organization level accommodates
+scenarios where orderers are run by different organizations. Using
+this configuration ensures that only the TLS CA certificates of that organization
+are used for orderer communications, in contrast to the global channel level endpoints which
+would cause an aggregation of all orderer TLS CA certificates across
+all orderer organizations to be used for orderer communications.
+
+**FAB-17428: Support for configtxgen flag `--outputAnchorPeersUpdate` is deprecated.**
+
+The `--outputAnchorPeersUpdate` mechanism for updating anchor peers has always had
+limitations (for instance, it only works the first time anchor peers are updated).
+Instead, anchor peer updates should be performed through the normal config update flow.
+
+**FAB-15406: The fabric-tools docker image is deprecated**
+
+The fabric-tools docker image will not be published in future Fabric releases.
+Instead of using the fabric-tools docker image, users should utilize the
+published Fabric binaries. The Fabric binaries can be used to make client calls
+to Fabric runtime components, regardless of where the Fabric components are running.
+
+**FAB-15317: Block dissemination via gossip is deprecated**
+
+Block dissemination via gossip is deprecated and may be removed in a future release.
+Fabric peers can be configured to receive blocks directly from an ordering service
+node by using the following configuration:
+```
+peer.gossip.orgLeader: true
+peer.gossip.useLeaderElection: false
+peer.gossip.state.enabled: false
+```
+
+**FAB-15061: Legacy chaincode lifecycle is deprecated**
+
+The legacy chaincode lifecycle from v1.x is deprecated and will be removed
+in a future release. To prepare for the eventual removal, utilize the v2.x
+chaincode lifecycle instead, by enabling V2_0 application capability on all
+channels, and redeploying all chaincodes using the v2.x lifecycle. The new
+chaincode lifecycle provides a more flexible and robust governance model
+for chaincodes. For more details see the
+[documentation for enabling the new lifecycle](https://hyperledger-fabric.readthedocs.io/en/release-2.2/enable_cc_lifecycle.html).
+
 
 Change log
 ----------