From a330b66e8c9f2d71d1d00812d481fd710de3942a Mon Sep 17 00:00:00 2001 From: David Enyeart Date: Wed, 11 Aug 2021 21:17:01 -0400 Subject: [PATCH] Add release notes for v2.4.0-beta release Add release notes for v2.4.0-beta release. Signed-off-by: David Enyeart --- Makefile | 2 +- release_notes/v2.4.0-beta.md | 167 +++++++++++++++++++++++++++++++++++ 2 files changed, 168 insertions(+), 1 deletion(-) create mode 100644 release_notes/v2.4.0-beta.md diff --git a/Makefile b/Makefile index 450ff9ca6ee..9752f9eca77 100644 --- a/Makefile +++ b/Makefile @@ -48,7 +48,7 @@ # - verify - runs unit tests for only the changed package tree ALPINE_VER ?= 3.13 -BASE_VERSION = 2.4.0 +BASE_VERSION = 2.4.0-beta # 3rd party image version # These versions are also set in the runners in ./integration/runners/ diff --git a/release_notes/v2.4.0-beta.md b/release_notes/v2.4.0-beta.md new file mode 100644 index 00000000000..dd6d4c6295c --- /dev/null +++ b/release_notes/v2.4.0-beta.md @@ -0,0 +1,167 @@ +v2.4.0-beta Release Notes - August 12, 2021 +=========================================== + +New features +------------ + +**[FABGW-1] Fabric Gateway** + +The Hyperledger Fabric v2.4.0 Beta contains the new Fabric Gateway feature. + +The Fabric Gateway is a new component that will implement much of the high-level 'gateway' programming model in the Fabric peer, +enabling the removal of much of the transaction submission and query logic from client applications, and shifting it to a common gateway component running within the Fabric peer. +The various client SDKs can therefore be slimmer, more consistent, and require less maintenance. + +The Fabric Gateway will also simplify the administrative overhead of running a Fabric network because client applications +will be able to connect and submit transactions via a single network port rather than the current situation where ports +have to be opened from a client application to multiple peers across potentially multiple organizations. + +The Fabric Gateway is delivered along with slim SDKs in the [https://github.com/hyperledger/fabric-gateway](https://github.com/hyperledger/fabric-gateway) repository. +Check out the [client application samples](https://github.com/hyperledger/fabric-gateway/tree/main/samples). + +**[FAB-11334] Unjoin a channel from a peer** + +The new command `peer node unjoin` enables an administrator to remove (unjoin) a channel from a peer. +The peer must be stopped when the command is executed so that channel artifacts can be cleaned up. +The channel's blockchain, state database, and associated entries will be removed from the peer. +When the peer is restarted it will no longer receive blocks for the channel. + +Improvements +------------ + +**peer and orderer - Implement legacy name constraints verification for Go 1.15** + +These changes reproduce the Go 1.14 name constraint verification in the MSP. +Without these changes, certificate chains that would fail verification in Go 1.14 would +successfully validate in Go 1.15 due to the change mentioned in the [Go 1.15 release notes](https://golang.org/doc/go1.15#commonname). +Specifically, if a signing certificate contains a name constraint, the leaf certificate +does not include SAN extensions, and the leaf's common name looks like a host name, +then the additional verification is performed to ensure deterministic behavior relative +to prior Fabric releases. + +**peer and orderer - Default log record format improvements** + +Expanded the width of the log record sequence number to a minimum of four characters, +moved the log sequence number and log level to the left, +and added bold formatting to the function name. +These changes keep the fixed-width columns together at the left +and add a visual break between the logging module name and log message text. + +**peer - New configuration option to disable gossip block forwarding** + +If all peers in an organization explicitly set "peer.deliveryclient.blockGossipEnabled" to false, +no peer in the organization gossips blocks to any other peer in that organization. +Use this setting when all peers pull blocks from ordering service. For more +information see deprecation announcement below: **FAB-15317: Block dissemination via gossip is deprecated**. + +**orderer - [FAB-18484] Return transaction forwarding result back to the client synchronously** + +With this improvement a Raft follower waits for the transaction to be forwarded to the Raft leader, +and returns the result (success or failure) back to the client accordingly. +Prior to this improvement, the Raft follower returned success after enqueueing it into the message queue, +which might have resulted in the transaction being dropped but a success being returned to the client. +Application clients should still monitor transaction commit events, since the Raft leader is not guaranteed +to deliver the transaction into a block in exception scenarios, but this improvement avoids +transactions from being dropped when there are connection issues between a Raft follower and Raft leader. + +**peer - Ability to override core.yaml chaincode.externalBuilders via environment variable** + +Since chaincode.externalBuilders is an array, it previously was not possible to set via environment variable override. +It is now possible to override chaincode.externalBuilders using an environment variable +using the format `CORE_CHAINCODE_EXTERNALBUILDERS=[{name: x, path: dir1}, {name: y, path: dir2}]`. + + +Fixes +----- +All fixes as of v2.3.2 are included in v2.4.0-beta. Additionally, the following fixes are made in v2.4.0-beta. + +**orderer - [FAB-18521] Consenters' metadata is not replicated while OSN catches up with snapshot** + +If an ordering service node crashes while replicating blocks from another ordering service, +the consenters metadata will not be available and the ordering service node will not be +able to reconnect to the consenter set upon restart. This fix ensures that an ordering +service node that is replicating blocks persists the consenters metadata so that it +can reconnect to the consenter set. + + +Dependencies +------------ +Fabric v2.4.0-alpha has been tested with the following dependencies: +* Go 1.15.7 +* CouchDB v3.1.1 +* Alpine images 3.13 + +Deprecations (existing) +----------------------- + +**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. + +**Fabric CouchDB image is deprecated** + +v2.2.0 added support 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/v2.2.0/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-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 and not gossip blocks by using the following configuration: +``` +peer.gossip.orgLeader: true +peer.gossip.useLeaderElection: false +peer.gossip.state.enabled: false +peer.deliveryclient.blockGossipEnabled: 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).