-
Notifications
You must be signed in to change notification settings - Fork 8.9k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add release notes for v2.4.0-beta release
Add release notes for v2.4.0-beta release. Signed-off-by: David Enyeart <enyeart@us.ibm.com>
- Loading branch information
Showing
2 changed files
with
168 additions
and
1 deletion.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -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). |