Validator is sending peer.TxValidationCode_INVALID_OTHER_REASON instead of
peer.TxValidationCode_ENDORSEMENT_POLICY_FAILURE due to a wrong type check.

Added UT to cover the switch and ensure correct tx flag been assigned.

Change-Id: I7abe8828323780d527b24905f54d9a06e5f70b4e
Signed-off-by: Srinivasan Muralidharan <muralisr@us.ibm.com>
Signed-off-by: Artem Barger <bartem@il.ibm.com>

The configtx validation code works by transforming the ConfigGroup tree
structure into a map, where each config element has a fully qualified
key like:

  [Groups] /Channel/Application

or

  [Policy] /Channel/Application/Readers

This flattened structure makes it easier to check which elements have
been modified, as the maps may simply be iterated over, rather than
walking the config tree.

After applying a config update, the current config map is copied, and
the elements which were updated are overlayed onto the old config.  This
map is then converted back into a tree structure and serialized to be
the new config tree.

The current code adopts the updated config map as the current config
map.  However, this produces the bug described in 5459.  Because the
updated config map is the overlay of the new config onto the old
config, the updated config may contain orphaned nodes which appear in
the map, but which do not appear in the config tree.

Consequently, when a subsequent update arrives, it is validated not
only against the current config, but also against the orphaned nodes
which are still in the updated config map.

This CR changes the logic to discard the updated config map (which may
contain this orphaned nodes) and instead has the config map recomputed
every time a new config is adopted.  This is more obviously
deterministic and mimics the way a new ordering node would initialize
the config after being restarted.

Note: There is no accompanying test case with this.  I had originally
written a test case which demonstrated that nodes were orphaned in the
updated config.  However, this is expected and not a useful test case.
Similarly, forcing the update config map to have updated nodes, then
testing that that map is not adopted does not provide a valuable test
case.

So, instead of a test, this CR opts for some code comments and this
lengthly commit explaining the change.

Change-Id: Idc847cd5e237531e4a8b978f3465e30a909eb94f
Signed-off-by: Jason Yellick <jyellick@us.ibm.com>

This CR prevents concurrent invokes from launching a chaincode
container at the same time (e.g. during performance testing). The first
invoke should succeed (and launch the container) while subsequent
invokes should fail until the container has finished launching.

Note: This does not change any behavior as subsequent invokes should
have failed but it now sends a clear error message that the chaincode
container is already launching.

Change-Id: Ic1772a5f25dd0e4c34278e6e7bdb8507f16269c8
Signed-off-by: Will Lahti <wtlahti@us.ibm.com>

Change-Id: Ib255d0f1601864bdaac9e6e272fa2fdc89b4f76b
Signed-off-by: Jay Guo <guojiannan1101@gmail.com>

System channel ID is hardcoded to 'testchainid' when using provisional
genesis method. This should be configurable so that we could run multiple
tests against a stateful service, e.g. Kafka, without cleaning up the
environment after each run. Otherwise, after the first run, later ones
would recognize 'testchainid' and recover states from it. Also, we meant
to deprecate this hardcoded manner anyway.

Note: this is for testing purpose only, so we don't expose it in the
orderer config yaml.

Change-Id: I60590f52c304e003e3dd74c27aa0f3bec3bb996a
Signed-off-by: Jay Guo <guojiannan1101@gmail.com>

The orderer metadata test only works if the development environment is
setup to set common.Version, because if this is not set, the version is
returned as "development version" and compared to the unset empty
string.

This is very annoying when trying to do development locally as this test
always fails.

This CR simply overrides the common.Version value for the purpose of
testing this package.

Change-Id: I6bc7a1de5a2730f4dd3fe17f1e5c7ff6bd81d4af
Signed-off-by: Jason Yellick <jyellick@us.ibm.com>

Change-Id: Ied54138605d42b2c7687dc0f80a5a0eb3befca34
Signed-off-by: Christopher Ferris <chrisfer@us.ibm.com>

This commit makes the peer relinquish its leadership if it can't
connect to the ordering service.

Change-Id: I5fe679d5f23e539828fea4a9398c7dd4d9fd0f93
Signed-off-by: yacovm <yacovm@il.ibm.com>

Change-Id: I34d23137eebfd9d5697061c1bf813b83543bcd05
Signed-off-by: Christopher Ferris <chrisfer@us.ibm.com>

Currently as stated in [FAB-5353], there is no clear separation during
transaction validation during block commmit, between invalid transaction
and some system failure which migh lead to inability to validate the
transaction. For example db is down or file system is unavailable. This
might lead to inconsistency of the state accross peers, therefore this
commit takes care to distinguish between real case of invalid
transaction versus system failure, later the error propagated down to
the committer and forces peer to stop with panic, so admin will be able
to take manual control and fix the problem therefore preventing peer
state to diverge.

Change-Id: I384e16d37e2f2b0fe144d504f566e0b744a5095c
Signed-off-by: Artem Barger <bartem@il.ibm.com>

This commit adjusts gossip files to have
the new SPDX license as required

Change-Id: Ia77ce6f1267a236e0df4b0b80450764534252a8a
Signed-off-by: yacovm <yacovm@il.ibm.com>

Change-Id: I46ab194a467dd5633b132f63e77505fe33f60a62
Signed-off-by: Christopher Ferris <chrisfer@us.ibm.com>

Add configtxlator 2 fabric-tools docker image

Change-Id: I36bd4677a393216e05d866aedac8a8f7206a96f3
Signed-off-by: rickr <cr22rc@gmail.com>

This change adds documentation on how to install the
Visual Studio C++ tools necessary to build the
Node.js native modules used in our samples.

Change-Id: I78277d937bcb5e697620b122061c6050d2570448
Signed-off-by: Arnaud J Le Hors <lehors@us.ibm.com>

Retry process should do an initial execution before starting
retry time ticker, otherwise there is a delay for each retry,
which accumulatively will cause slow start of kafka chain.

Change-Id: I9c2aafeb73e366b72d94e317088548e4754ee8c4
Signed-off-by: Jay Guo <guojiannan1101@gmail.com>

update chaintool version and URL to download chaintool binary
from nexus repository

Change-Id: I871eea4106a6e0c59a3a9660d475026d6d2e5481
Signed-off-by: rameshthoomu <rameshbabu.thoomu@gmail.com>

The state transfer module receives blocks from either the orderer
or other peers, and puts them into a payload buffer for reordering so
they would enter the ledger in-order.

In some cases:
- If the peer joined late and it receives blocks from peers starting from
  index i where the ledger is missing indices [j, i] for some j<i
  and the rate of block reception from peers is very fast
- If the ledger is "stuck" (i.e file system full, etc.) and cannot advance

This buffer would overpopulate.

This commit addresses this, and adds a maximum distance constant
that if the difference between the ledger height and the sequence
of the block that is received is greater than this constant,
the block is dropped.

Change-Id: Ia1ba8966ea6d211c5d1b7ddd84a4fad34af797d4
Signed-off-by: yacovm <yacovm@il.ibm.com>

Change-Id: Iadf71f9c8b34716a8d785767e73ab154a249df78
Signed-off-by: Scott Zwierzynski <scottz@us.ibm.com>