github.com/osdi23p228/fabric@v0.0.0-20221218062954-77808885f5db/release_notes/v2.2.0.md (about)

     1  v2.2.0 Release Notes - July 9, 2020
     2  ===================================
     3  
     4  What's New in Hyperledger Fabric v2.2
     5  -------------------------------------
     6  
     7  **FAB-13460: Add Support for TLS 1.3**
     8  
     9  TLS 1.3 is now supported and will be utilized automatically if client supports TLS 1.3.
    10  
    11  **FAB-17401: Add function to query the details of the approved chaincode definition**
    12  
    13  Add support to query an organization's approved chaincode definition from its peer.
    14  The function is available by using peer CLI command `peer lifecycle chaincode queryapproved`.
    15  
    16  
    17  Fixes
    18  -----
    19  
    20  **Return Error From PKCS11 CreateSession**
    21  
    22  The prior implementation of BCCSP performed a fatal
    23  logging function in the event it could not open a session
    24  with the HSM.  It was possible for the fatal log to occur when an expected error
    25  occurred, i.e., the HSM had reached its maximum session handles.
    26  Instead of issuing a fatal log call, an error is returned so that
    27  the error can be properly handled.
    28  
    29  **FAB-17819: Discovery returns user friendly errors**
    30  
    31  Service discovery endorsement service error message "cannot satisfy any principal combination" is
    32  improved to return a more specific message, either "no peer combination can satisfy the endorsement policy"
    33  or "required chaincodes are not installed on sufficient peers".
    34  
    35  **FAB-17774: Support orderer restart without system channel genesis block**
    36  
    37  When BootstrapMethod was set to 'file', the system channel genesis block
    38  was required to be passed for every orderer service start. The system
    39  channel genesis block is now only required for the initial orderer start.
    40  
    41  **FAB-17844: External builder fails to copy symlinks from build output into persistent directory**
    42  
    43  Previously, the external builder code did not check for symlinks in build output when copying them.
    44  This resulted in the resolved files being copied as files instead of symlinks. The external builder
    45  now copies them as symlinks instead of copying them as files into the destination directory.
    46  
    47  **Errors should be checked when orderer gRPC server is serving requests**
    48  
    49  gRPC errors are now checked when servicing the orderer atomic broadcast gRPC service.
    50  
    51  **FAB-17900: Fix environment variable override bug**
    52  
    53  Integer config values for peer and orderer could not be overridden with environment variables.
    54  
    55  **FAB-17951: Fetch correct node id for orderer consenter validation**
    56  
    57  Config update validator may incorrectly reject updates if some nodes are inactive.
    58  
    59  **FAB-17875: Fix ordering service node leader election failure**
    60  
    61  Previously with Raft consensus, when one ordering service node was deleted
    62  from a channel and rejoined later, it would be assigned a new Raft id.
    63  However, in some cases the ordering service node still used the old Raft
    64  id. Other ordering service nodes including the leader are using the latest view and believe
    65  that the rejoined node would use a new Raft id.  This may result in leader election failure and no new
    66  transactions would be accepted. The fix ensures the correct Raft id is used after tracking the latest config block.
    67  
    68  **Private data performance optimization: purge transient store in background**
    69  
    70  Private data performance is improved by purging entries present in the transient store in the background.
    71  
    72  **FAB-17933: Fix cache update logic for installed chaincode info when an empty or uninstalled package ID is specified**
    73  
    74  Previous cache update logic for install chaincode info did not work properly when an empty or uninstalled package ID was specified.
    75  
    76  **FAB-17539: Always remember gossip anchor peers in membership**
    77  
    78  Gossip removes a peer from its membership cache if no new heartbeats are received from the peer within a timely manner.
    79  If a network partition persists for too long, peers of different organizations never re-establish communication because all membership is purged.
    80  With the fix, anchor peers are no longer removed from the membership cache even if they are offline.
    81  Therefore, after the network partition is healed, peers among different organizations can reestablish communication as long as anchor peers are reachable.
    82  
    83  **Note: Fixes included in v2.1.1 release notes are also included in v2.2.**
    84  
    85  Changes
    86  -------
    87  
    88  **FAB-17786: upgrade_dbs peer command now drops state CouchDB databases**
    89  
    90  Previously the upgrade_dbs command did not automatically drop state CouchDB
    91  databases and therefore a separate step was required to drop CouchDB data
    92  when upgrading to v2.x. upgrade_dbs command now automatically drops
    93  state CouchDB databases. CouchDB state database will get rebuilt on the first
    94  peer start after the upgrade to v2.x. CouchDB database service
    95  must be available when running upgrade_dbs command. Similarly,
    96  rebuild-dbs also drops state CouchDB data now, so that state database
    97  can be rebuilt on the next peer start.
    98  
    99  **FAB-17869: Allow TLS CAs with overlapping issuers**
   100  
   101  The client root TLS CA certificate pool construction didn't allow different issuers
   102  with the same subject name to exist in the CA cert pool. Different issuers with
   103  the same subject name are now allowed.
   104  
   105  **Fabric CouchDB tests have been updated from CouchDB 2.3.1 to CouchDB 3.1.0**
   106  
   107  Support is added for CouchDB 3.1.0 as the recommended and tested version of CouchDB.
   108  If prior versions are utilized, a Warning will appear in peer log.
   109  Note that CouchDB 3.1.0 requires that an admin username and password be set,
   110  while this was optional in CouchDB v2.x. See the
   111  [Fabric CouchDB documentation](https://hyperledger-fabric.readthedocs.io/en/release-2.2/couchdb_as_state_database.html#couchdb-configuration)
   112  for configuration details.
   113  Also note that CouchDB 3.1.0 default max_document_size is reduced to 8MB. Set a higher value if needed in your environment.
   114  Finally, the fabric-couchdb docker image will not be updated to v3.1.0 and will no longer be updated, maintained, or published.
   115  Users can utilize the official CouchDB docker image maintained by the Apache CouchDB project instead.
   116  
   117  **FAB-17917: Peer CouchDB default `maxRetriesOnStartup` property has been updated**
   118  
   119  Peer property `peer.ledger.state.couchDBConfig.maxRetriesOnStartup` default has
   120  changed from 12 to 10. The time between retries doubles after each attempt.
   121  Therefore if CouchDB is not yet started, the peer start will now retry
   122  for about 2 minutes rather than 16 minutes before retries are exhausted.
   123  
   124  **FAB-16435: Peer gossip defaults have been updated**
   125  
   126  Block dissemination via gossip may be removed in a future release,
   127  since it is more straightforward for peers to simply pull blocks from ordering service.
   128  The gossip defaults have been updated to prepare users for this possible change, so that peers by default
   129  pull blocks from ordering service, do not use leader election, and do not use block transfer across peers.
   130  Additionally, two block cache default sizes have been lowered to reduce the memory
   131  used by a peer when it has joined many channels.
   132  The new defaults are as follows:
   133  ```
   134  peer.gossip.orgLeader: true
   135  peer.gossip.useLeaderElection: false
   136  peer.gossip.state.enabled: false
   137  peer.gossip.maxBlockCountToStore: 10
   138  peer.gossip.state.blockBufferSize: 20
   139  ```
   140  Default configuration values are included in the peer docker image, therefore if you apply
   141  the new peer image the new defaults will be effective unless you specifically override them
   142  in your configuration.
   143  
   144  **Build Your First Network sample and tutorial has been removed**
   145  
   146  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,
   147  and to review the new [deployment guides](https://hyperledger-fabric.readthedocs.io/en/release-2.2/deployment_guide_overview.html).
   148  
   149  **FAB-18028: Replace `environmentWhiteList` peer property with `propagateEnvironment`**
   150  
   151  Peer configuration property `peer.chaincode.externalBuilders.environmentWhiteList` has been replaced with `peer.chaincode.externalBuilders.propagateEnvironment`.
   152  `environmentWhiteList` continues to work but is deprecated.
   153  
   154  
   155  Dependency updates
   156  ------------------
   157  Fabric project now uses Go modules for vendoring code dependencies.
   158  
   159  Bump Go gRPC to 1.29.1.
   160  
   161  Bump Go to 1.14.4.
   162  
   163  Bump Alpine to 3.12 in Fabric images.
   164  
   165  CouchDB 3.1.0 is now the tested CouchDB version.
   166  
   167  
   168  Deprecations
   169  ------------
   170  
   171  **FAB-15754: The 'Solo' consensus type is deprecated.**
   172  
   173  The 'Solo' consensus type has always been marked non-production and should be in
   174  use only in test environments, however for compatibility it is still available,
   175  but may be removed entirely in a future release.
   176  
   177  **FAB-16408: The 'Kafka' consensus type is deprecated.**
   178  
   179  The 'Raft' consensus type was introduced in v1.4.1 and has become the preferred
   180  production consensus type.  There is a documented and tested migration path from
   181  Kafka to Raft, and existing users should migrate to the newer Raft consensus type.
   182  For compatibility with existing deployments, Kafka is still supported,
   183  but may be removed entirely in a future release.
   184  Additionally, the fabric-kafka and fabric-zookeeper docker images are no longer updated, maintained, or published.
   185  
   186  **FAB-7559: Support for specifying orderer endpoints at the global level in channel configuration is deprecated.**
   187  
   188  Utilize the new 'OrdererEndpoints' stanza within the channel configuration of an organization instead.
   189  Configuring orderer endpoints at the organization level accommodates
   190  scenarios where orderers are run by different organizations. Using
   191  this configuration ensures that only the TLS CA certificates of that organization
   192  are used for orderer communications, in contrast to the global channel level endpoints which
   193  would cause an aggregation of all orderer TLS CA certificates across
   194  all orderer organizations to be used for orderer communications.
   195  
   196  **FAB-17428: Support for configtxgen flag `--outputAnchorPeersUpdate` is deprecated.**
   197  
   198  The `--outputAnchorPeersUpdate` mechanism for updating anchor peers has always had
   199  limitations (for instance, it only works the first time anchor peers are updated).
   200  Instead, anchor peer updates should be performed through the normal config update flow.
   201  
   202  **FAB-15406: The fabric-tools docker image is deprecated**
   203  
   204  The fabric-tools docker image will not be published in future Fabric releases.
   205  Instead of using the fabric-tools docker image, users should utilize the
   206  published Fabric binaries. The Fabric binaries can be used to make client calls
   207  to Fabric runtime components, regardless of where the Fabric components are running.
   208  
   209  **FAB-15317: Block dissemination via gossip is deprecated**
   210  
   211  Block dissemination via gossip is deprecated and may be removed in a future release.
   212  Fabric peers can be configured to receive blocks directly from an ordering service
   213  node by using the following configuration:
   214  ```
   215  peer.gossip.orgLeader: true
   216  peer.gossip.useLeaderElection: false
   217  peer.gossip.state.enabled: false
   218  ```
   219  
   220  **FAB-15061: Legacy chaincode lifecycle is deprecated**
   221  
   222  The legacy chaincode lifecycle from v1.x is deprecated and will be removed
   223  in a future release. To prepare for the eventual removal, utilize the v2.x
   224  chaincode lifecycle instead, by enabling V2_0 application capability on all
   225  channels, and redeploying all chaincodes using the v2.x lifecycle. The new
   226  chaincode lifecycle provides a more flexible and robust governance model
   227  for chaincodes. For more details see the
   228  [documentation for enabling the new lifecycle](https://hyperledger-fabric.readthedocs.io/en/release-2.2/enable_cc_lifecycle.html).
   229  
   230  
   231  Change log
   232  ----------
   233  For the full list of changes, refer to the release change log:
   234  https://github.com/osdi23p228/fabric/blob/release-2.2/CHANGELOG.md#v220