From 54c1cada7621bbb046963682dddda78ee4ce029b Mon Sep 17 00:00:00 2001 From: David Enyeart Date: Wed, 10 Jul 2019 09:56:23 -0400 Subject: [PATCH] [FAB-15908] Add release notes for v1.4.2 FAB-15908 #done Change-Id: I147a8988ad671ecbbb62d9cbabcb19ecb1edbff8 Signed-off-by: David Enyeart --- release_notes/v1.4.2.txt | 158 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 158 insertions(+) create mode 100644 release_notes/v1.4.2.txt diff --git a/release_notes/v1.4.2.txt b/release_notes/v1.4.2.txt new file mode 100644 index 00000000000..29c2e25175d --- /dev/null +++ b/release_notes/v1.4.2.txt @@ -0,0 +1,158 @@ +v1.4.2 Release Notes - July 17, 2019 +------------------------------------ + +What's New in Hyperledger Fabric v1.4.2 +--------------------------------------- + +The following features are included in this release: + +FAB-15041 - Kafka to Raft Consensus Migration +A Kafka-based ordering service can now be migrated to utilize Raft consensus. +For details see the documentation at +https://hyperledger-fabric.readthedocs.io/en/latest/kafka_raft_migration.html. +This feature requires v1.4.2 'orderer' and 'channel' capabilities to be +enabled. + +FAB-14307 Channel rollback on a peer +The new 'peer node rollback' command provides +administrative ability to rollback a channel's ledger on a peer to a prior +block height in the case a peer's channel data gets into a corrupt state at a +later block height. The peer will re-retrieve the rolled back blocks from +ordering service or another peer upon the next peer start. Note that during +the rollback, the ledger's private data will be preserved, since it cannot +be obtained from ordering service at a later time, and may not be available +from other peers. +Similarly, the command 'peer node reset' command can be used to rollback +all of a peer's channel ledgers to the genesis block of each channel. +Both commands must be issued from the peer's CLI while the peer process +is down. +It is recommended to enable v1.4.2 'application' capability to ensure that all +private data is stored on the local peer (including for invalidated transactions), +in case rollback and reprocessing is required on a peer. + +FAB-7559 - Ability to specify orderer endpoints at the organization level +Starting from version v1.4.2, it is possible and highly recommended to define +orderer endpoints at the organization level (new 'OrdererEndpoints' stanza +within the channel configuration of an organization) and not at the global +'Orderer.Addresses' section of channel configuration. If at least one +organization has an ordering service endpoint defined at an organizational +level, all orderers and peers will ignore the channel level endpoints when +connecting to ordering nodes. +Utilizing organization level orderer endpoints is required when using +service discovery with orderer nodes provided by multiple organizations, +so that clients can provide the correct organization TLS certificates. +This feature requires v1.4.2 'channel' capability to be +enabled. + + +Important Fixes +--------------- +FAB-15450 - History database queries do not return all results +Prior to the fix, history database queries excluded transactions from +blocks that were multiples of 256 (block 256, 512, 768, etc). + +FAB-15411 - GetTransactionByID does not return configuration transactions +Prior to the fix, GetTransactionByID and GetBlockByTxID did not return +configuration transactions, since these transactions were not indexed +correctly. To fix indexes for pre-existing configuration transactions +on a peer's channel ledgers, stop the peer and delete the index directory, +e.g. /var/hyperledger/production/ledgersData/chains/index directory. +The peer will rebuild the indexes correctly upon the next restart. + +FAB-15404 - Orderer Kafka TLS Issue +Prior to the fix, orderer nodes could not communicate to kafka if +TLS is enabled. + +FAB-15144 - Assorted orderer serviceability fixes + + +Changes, Known Issues, and Workarounds +-------------------------------------- +FAB-15031 - ledger.blockstorage_commit_time metric is available on orderer nodes +ledger.blockstorage_commit_time is now available on both peer and orderer nodes, +but only includes block storage commit time. A new metric, +ledger_blockstorage_and_pvtdata_commit_time, is available on peer nodes and +includes the total commit time for blockstorage and pvtdata. + +FAB-15549 - Restrict service discovery endorsement computation +If the endorsement policy contains an NoutOf that yields too many combinations +(such as - 13 out of 25), service discovery will not return all possible +combinations to the application (as that number can be huge), but instead will +return a random subset of endorsement combinations. + +FAB-12088 - Java chaincode support on s390x architecture +Java chaincode support is not available on s390x architecture. + +FAB-12134 - Same chaincode source receiving fingerprint mismatch error +Chaincode installed in different ways may result in "chaincode fingerprint +mismatch data mismatch" error upon instantiation. This may happen when +installing chaincode by using different SDKs. To workaround the problem, +package the chaincode prior to installation and instantiation, by using +the "peer chaincode package" command. + + +Known Vulnerabilities +--------------------- +FAB-8664 - Peer should detect and react when its org has been removed +This is a relatively low severity problem, because it requires a significant +conspiracy of network admins, but it will be addressed in a future release. + + +Resolved Vulnerabilities +------------------------ +None. + + +Deprecations +------------ +The following functions are deprecated and are targeted for removal in a future release. + +Support for automatically vendoring the chaincode shim into user chaincodes. +The fabric-ccenv image which is used to build chaincode, currently includes +the github.com/hyperledger/fabric/core/chaincode/shim ("shim") package. +This is convenient, as it provides the ability to package chaincode +without the need to include the "shim". However, this may cause issues in future +releases (and/or when trying to use packages which are included by the "shim"). +In order to avoid any issues, users are advised to manually vendor the "shim" +package with their chaincode prior to using the peer CLI for packaging and/or +for installing chaincode. +For more details see FAB-5177. + +Support for CAR chaincode package format +Support for packaging chaincode using the CAR format will be removed in +a future release. +For more details see FAB-14720. + +Support for specifying orderer endpoints at the global level in channel configuration. +Utilize the new 'OrdererEndpoints' stanza within the channel configuration of +an organization instead. +For more details see FAB-7559. + +Support for invoking system chaincodes from user chaincodes. +System chaincodes, for example QSCC, are intended to be invoked by +a client rather than by a user chaincode. Invoking from a user chaincode +may cause deadlocks. +For more details see FAB-15285. + +Support for user chaincodes to utilize the chaincode shim's logger via NewLogger(). +Chaincodes that used the shim's NewLogger() will need to shift to their own preferred +logging mechanism. +For more details see FAB-15366. + +Support for peer's Admin service. +The peer's Admin service exposes APIs such as GetLogSpec() and SetLogSpec(). +Instead of using these services, utilize the HTTP operations service that was +introduced in v1.4.0. +For more details see FAB-15390. + +Support for Solo ordering service. +With the introduction of Raft-based ordering service in v1.4.1, it is possible +to deploy a single-node (non-production) or multi-node +Raft-based ordering service with no external dependencies. +For single-node (non-production) ordering services, utilize Raft-based ordering +service with a single node instead of Solo ordering service. +For more details see FAB-15754. + + +For the full list of improvements and fixes, refer to the release change log: +https://github.com/hyperledger/fabric/blob/release-1.4/CHANGELOG.md#v142