-
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.
Signed-off-by: David Enyeart <enyeart@us.ibm.com>
- Loading branch information
Showing
1 changed file
with
62 additions
and
0 deletions.
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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,62 @@ | ||
v2.1.1 Release Notes - May XX, 2020 | ||
=================================== | ||
|
||
Fixes | ||
----- | ||
|
||
**FAB-17778: Fix policy support of multiple signatures from single organization** | ||
|
||
Fix de-duplication logic to ensure sufficient number of signatures are received to satisfy | ||
policies that require multiple signatures from the same organization. | ||
This problem is rare since most users have policies that require signatures from different | ||
organizations, not policies that require multiple signatures from the same organization. | ||
|
||
**FAB-17722: Validate HSM session and get new if invalid** | ||
|
||
Previously the pkcs11 code was set to have a session cache and reuse sessions | ||
if available in cache. If a session went bad (due to connection issues with HSM), | ||
the session was not evicted from cache and would be reused. | ||
If all sessions went bad, the client would never be able to recover and keep using bad sessions. | ||
|
||
**FAB-17728: Add delay to pkcs11 create session loop** | ||
|
||
Previously there was no backoff when attempting to create a new session if one was not | ||
available in the HSM session cache. This fix introduces a hardcoded backoff of 100ms | ||
after each attempt up to 10. | ||
|
||
**FAB-17784: Clarify error message when legacy chaincode install fails during build** | ||
|
||
When a legacy chaincode install fails due to an error building the | ||
chaincode, the chaincode will remain installed on the peer. This change clarifies | ||
the error message so that users understand the behavior: | ||
"chaincode installed to peer but could not build chaincode". | ||
|
||
**FAB-17844: Copy symlinks as-is in external builder output** | ||
|
||
Previously, the external builder code did es not check for symlinks in build output | ||
when copying them. This resulted in the resolved files being copied as files | ||
instead of symlinks. This commit changes the external builder code so that | ||
it tests for symlinks, and copies them as symlinks instead of copying them as | ||
files into the destination directory. | ||
|
||
**External builder switch from os.Stat to exec.LookPath** | ||
|
||
Replace call to os.Stat to check for the presence of the bin/release script with exec.LookPath. | ||
The LookPath function, when provided with a relative path, will look for the presence of the | ||
executable and determine if it's executable. On non-unix platforms, it will also handle looking | ||
for executable suffixes as appropriate. | ||
|
||
**FAB-17907: New chaincode lifecycle should ignore previous build failure during install** | ||
|
||
When a chaincode build previously failed while installing the chaincode, the new lifecycle | ||
would not attempt to rebuild the chaincode on the next install attempt, rather the prior | ||
build error message was returned to the client. This change ensures that the subsequent | ||
install attempt rebuilds the chaincode. | ||
|
||
**FAB-17733: Validate TLS certs during raft consenter addition** | ||
|
||
Validate the client/server TLS certs against the orderer organizations while adding a raft consenter. | ||
|
||
|
||
For the full list of changes, refer to the release change log: | ||
https://github.com/hyperledger/fabric/blob/release-2.1/CHANGELOG.md#v211 |