Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update base #23

Merged
merged 13 commits into from May 8, 2020
Merged

Update base #23

merged 13 commits into from May 8, 2020

Conversation

xhens
Copy link
Owner

@xhens xhens commented May 8, 2020

Type of change

  • Bug fix
  • New feature
  • Improvement (improvement to code, performance, etc)
  • Test update
  • Documentation update

Description

Additional details

Related issues

yacovm and others added 13 commits April 30, 2020 18:51
Currently, the discovery service filters out peers that don't have the chaincode installed
early on in the computation, and as a result - the service cannot distinguish from a case
where there are not enough alive peers to satisfy the endorsement policy, or that there are
enough peers but the chaincode is not installed on enough of them.

This change set defers the chaincode filtering to the end of the computation, so
the layouts and peer group mapping is creating without taking into account if the peers
have the chaincode installed on them, and if there is no layout that can be satisfied
without taking into account the chaincodes - the error that is returned now
is "no peer combination can satisfy the endorsement policy",
instead of "cannot satisfy any principal combination".

Afterwards, the layouts are being inspected once again, and then the layouts
that cannot be satisfied are filtered out, when the error returned
when no layout can be satisfied is now: "required chaincodes are not installed on sufficient peers".

Change-Id: I74eb29b30aec1a87842d220414c73872cdbc8304
Signed-off-by: yacovm <yacovm@il.ibm.com>
Signed-off-by: Matthew Sykes <matthew.sykes@gmail.com>
)

The existing upgrade_dbs command does not automatically drop state couchdbs
and therefore a separate step is required to drop couchdbs, This PR updates
the command to automatically drop state couchdbs.

In addition, it checks upgrade eligibility before upgrade so that it will not
drop databases if it is already the expected format.

Signed-off-by: Wenjian Qiao <wenjianq@gmail.com>
* adding support for orderer restart without genesis block.

Signed-off-by: Chongxin Luo <Chongxin.Luo@ibm.com>
- Removed the interface for better code navigation, as There is only a
 single implementation for block storage
- Merged the remaining code in the package blkstorgae with the
implementation in the package fsblkstorage and used the name
blkstorgae for the final package
- Moved the internal single proto message with in same package

Signed-off-by: manish <manish.sethi@gmail.com>
- mv updateBatch bytes constructor to txmgr pkg
Currently, we create the bytes representation of updateBatch
to compute the hash of updateBatch which would be included in
the block along with the validation results. The utility for
converting a updateBatch to a deterministic bytes is present
in the privacyenabledstate pkg. However, this utility is
used only by the txmgr and hence, we move the utility
function to txmgr pkg from privacyenabledstate pkg.

- rename proto messages
In the updateBatch proto, we have defined proto messages such
as KVWriteProto and KVWriteBatchProto. As we shouldn't append
the keyword proto to messages, we rename KVWriteProto to KVWrite
and KVWriteBatchProto to Updates.

- rename function names
The function name such as buildForKeys(), buildForColls() are not
very explicit in what they do. When the buildForColls() calls
buildForKeys(), it adds even more confusion as the first-level
function, i.e., deterministicBytesForPubAndHashUpdates() is also
calling buildForKeys(). Hence, we have used the following function
names instead:
(1) genKVsFromNsUpdates()
(2) genKVsFromCollsUpdates()
(3) genKVs()

FAB-17830

Signed-off-by: senthil <cendhu@gmail.com>
Signed-off-by: Gari Singh <gari.r.singh@gmail.com>
Currently Version1x and Version20 are defined in dataformat.go.
They should be renamed to more generic names such as
PreviousFormat and CurrentFormat.

The format values will change only when the data format is changed
in ledger. If a Fabric version does not introduce a new data format,
CurrentFormat will remain the same as the latest format prior to
the Fabric version.

Signed-off-by: Wenjian Qiao <wenjianq@gmail.com>
rm pvtdatastorage interfaces

As we have only one implementation of the pvtdatastore and not
planning to any a new one, we can safely remove the interface.
This also helps in code navigation and to avoid type casting
such as s.(*store) in the test.

FAB-17843

Signed-off-by: senthil <cendhu@gmail.com>
- Expose a configuration object for channel participation at
  the top level (like Metrics). Even though the channel
  participation API shares the same endpoint and TLS config
  with operations, placing it at the top level will allow us
  to separate these APIs to different endpoints in the future
  without changing the config structure.

- Extend operations.System to be able to register a handler
  for additional APIs.

- Implement a skeleton handler for the channel participation API.

- Register the skeleton handler to the http server in
  operations.System during the server boot sequence.

Signed-off-by: Yoav Tock <tock@il.ibm.com>
Change-Id: I5cf15dffa29985cba60e5aaf31d189e755a3a1ef
- Remove GOPATH in favor of modules
- Move to Ubuntu 20.04
- Remove docker-compose as it's unnecessary for build and test

Signed-off-by: Matthew Sykes <sykesmat@us.ibm.com>
FAB-17837

Signed-off-by: manish <manish.sethi@gmail.com>
As the number of arguments passed to newKVLedger(),
initTxMgr() is quite high, we reduce it by introducing
initializer struct.

FAB-17683

Signed-off-by: senthil <cendhu@gmail.com>
@xhens xhens self-assigned this May 8, 2020
@xhens xhens merged commit a233313 into xhens:master May 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
9 participants