The configtx code uses an 'append(...)' against a slice, and records the
new slice address when computing the config map.  Through sheer dumb
luck, this code works for config groups which are only nested 2 levels
deep, because the append call triggers a true new memory allocation.
However, for config groups 3 levels deep (such as consortium groups),
the append call actually re-uses the underlying memory for the slice.

This causes the path to be corrupted internally for the consortium group
items, and cause the wrong policy to be resolved when checking for a
policy which has been specified relatively.

This fix manually allocates new memory, copies it, and then appends the
element.

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

There is a map access that isn't protected by a lock
that was introduced in a recent commit.

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

With this change the documentation instructs Windows users
to work within the Docker Quickstart Terminal rather than
Git Bash which does not work for Windows 10.
This change also adds a note to the first curl command to
address the recurrent problem with Windows users reporting
failure due to using an outdated version of curl.

Patch-set #2: added a piece about installing npm grpc based
on users reporting this was necessary.

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

Rename a method in benchmark test to be more precise.
Also a typo in blockfile_mgr.go is fixed.

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

This fix appends a hash of the Docker image name to the image name
to ensure a chaincode with different capitalization does not override
the container of an already instantiated chaincode. This problem was
introduced by the need to convert all Docker image names to lowercase.
The Docker container name will retain its capitalization as that
restriction only applies to the image name.

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

The multichannel (formerly multichain) package became a bit of a dumping
ground for all of the interface definitions used in the orderer system.
this makes the multichannel package clunky, difficult to mock, and
encourages poor separation between components.

This CR extracts the interface definitions and moves them to more
sensible locations based on the natural separation of function within
the orderer codebase.

It is also fixed the multichannel package to generally return pointers
to structs, rather than to interfaces, following the golang best
practice of accepting interfaces and returning structs.

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

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

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>

Currently, configtxlator outputs configs with default fields omitted.
This means for instance that if a value has not been changed, its
version at 0 is not printed.  Similarly, if there is no CRL defined, the
CRL field is not printed.

Based on multiple reports, this behavior seems to be more confusing than
helpful.  This CR changes the code to turn the emit defaults flag on.

Change-Id: I4b393f4eb0473fd3e7ee09b7db6ccc4ac7c1932c
Signed-off-by: Jason Yellick <jyellick@us.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 configtxlator doc references the common.Configuration type which
does not exist.  Instead, it intends to refer to common.Config.

This CR fixes this in both the rst and the md.

Change-Id: I10bf0b6013e81411006c53b548afd7060021bac0
Signed-off-by: Jason Yellick <jyellick@us.ibm.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>