github.com/kaituanwang/hyperledger@v2.0.1+incompatible/release_notes/v1.4.0.txt (about)

     1  v1.4.0 Release Notes - January 9, 2019
     2  --------------------------------------
     3  
     4  What's New in Hyperledger Fabric v1.4
     5  -------------------------------------
     6  
     7  The following features are included in this release:
     8  
     9  Fabric operations service
    10  A new HTTP based "operations" endpoint has been implemented on the orderer and
    11  the peer. The endpoint exposes APIs to check the server's health, to query
    12  and modify the logging level of the process, and, when configured, to expose
    13  Fabric metrics.
    14  
    15  FAB-3388 - Operational metrics for Fabric components
    16  The peer and orderer have been instrumented to provide basic operational
    17  metrics. The metrics can be surfaced for consumption by Prometheus or StatsD.
    18  
    19  FAB-10851 - Health check endpoint
    20  The orderer and the peer now provide a mechanism to check the health of the
    21  process via an HTTP request. Requests to GET /healthz on the operations
    22  endpoint will complete with a status 200 OK when the server believes it is
    23  healthy. When a health check fails, the server will respond with a 503 Service
    24  Unavailable and a JSON payload indicating which component detected an issue.
    25  The types of health checks that are performed will be extended over time.
    26  
    27  FAB-12265 - Dynamic log levels
    28  The orderer and the peer now provide a mechanism to get and update the active
    29  logging specification of the server. Requests to GET /logspec on the
    30  operations endpoint will return with a JSON payload that contains the active
    31  spec. When a JSON payload of `{"spec":"the-log-spec"}` is sent as the body of
    32  a PUT /logspec request, the active logging spec will be updated.
    33  
    34  FAB-12357 - Updates to logging
    35  In earlier versions of Fabric, loggers were associated with named components
    36  and configuration would control the active level of each logger. While this
    37  model works in theory, because of the configuration management libraries used
    38  by Fabric and the structure of the Fabric code base, in practice it had a
    39  number of issues.
    40  With 1.4, we're changing the model slightly. Instead of associating loggers
    41  with components, we are naming loggers and to help avoid side effects during
    42  initialization, the logging configuration is no longer obtained from the
    43  fabric configuration system but from environment variables that define
    44  the logging specification and log format.
    45  The log specification is a single string that consists of colon separated
    46  tokens. Each token declares one or more logger name prefixes (separated by
    47  commas) and an optional log level. When the logger name prefix ends with a
    48  period, it indicates that the log level should only apply to the logger with
    49  that exact name without the trailing period. When the logger name pattern is
    50  omitted, it specifies the default log level. In cases where multiple entries
    51  reference the same name pattern or multiple instances of a default are
    52  provided, the last specification takes precedence.
    53  
    54  FAB-12363 - Logging for gRPC interactions
    55  The orderer and the peer now provide logging (INFO level) for each gRPC
    56  interaction completed.
    57  
    58  FAB-12372 - Obtain Go routine stacks without termination
    59  When SIGUSR1 is received by the peer or the orderer, the state of all go
    60  routines will be captured and logged at the INFO level. This collection
    61  activity will not terminate the process.
    62  
    63  FAB-5093 - Private data reconciliation
    64  Allows peers for organizations that are added to private data collections
    65  to retrieve the private data for prior transactions to which they now are
    66  entitled. This feature is only supported on peers that have joined
    67  a channel since v1.4.
    68  
    69  FAB-11409 - Private data client access control
    70  Ability to automatically enforce access control within chaincode based
    71  on the client organization collection membership without having to
    72  write specific chaincode logic. This feature is configured by using
    73  the collection configuration property memberOnlyRead:true. If you have
    74  a mixed network of v1.4 peers and prior release peers, the prior
    75  release peers will not honor this configuration until they are upgraded
    76  to v1.4.
    77  
    78  
    79  Changes, Known Issues, and Workarounds
    80  --------------------------------------
    81  
    82  FAB-12357 - Updates to logging
    83  Instead of using logging.level and CORE_LOGGING_LEVEL to control the logging
    84  level for the peer, and General.LogLevel or ORDERER_GENERAL_LOGLEVEL to
    85  control logging at the orderer, both processes now use the FABRIC_LOGGING_SPEC
    86  environment variable to acquire the initial logging specification for the
    87  server. Existing logging configuration should be converted to the new model.
    88  
    89  FAB-12489 - peer logging command updates
    90  The `getlevel`, `setlevel`, and `revertlevels` subcommands of the `peer
    91  logging` command are deprecated and users should migrate to the operations
    92  server.
    93  The behavior of `setlevel` has also changed slightly. The previous
    94  implementation would treat the `logger` argument as a regular expression and
    95  apply the new log level to all loggers that matched the expression. The
    96  updated implementation treats the `logger` argument as a logger name and
    97  appends it to the active logging spec at the indicated level.
    98  
    99  FAB-12088 - Java chaincode support on s390 architecture
   100  Java chaincode support is not yet available on s390 architecture.
   101  
   102  FAB-12134 Same chaincode source receiving fingerprint mismatch error
   103  Chaincode installed in different ways may result in "chaincode fingerprint
   104  mismatch data mismatch" error upon instantiation.  This may happen when
   105  installing chaincode by using different SDKs. To workaround the problem,
   106  package the chaincode prior to installation and instantiation, by using
   107  the "peer chaincode package" command.
   108  
   109  Known Vulnerabilities
   110  ---------------------
   111  FAB-8664 - Peer should detect and react when its org has been removed
   112  This is a relatively low severity problem, because it requires a significant
   113  conspiracy of network admins, but it will be addressed in a future release.
   114  
   115  Resolved Vulnerabilities
   116  ------------------------
   117  None.
   118  
   119  Other improvements and fixes
   120  ----------------------------
   121  Updated to Go version 1.11.1
   122  Updated baseimage version to 0.4.14
   123  
   124  For the full list of improvements and fixes, refer to the release change log:
   125  https://github.com/hyperledger/fabric/blob/release-1.4/CHANGELOG.md#v140