Skip to content
GitLab
  1. 27 Jul, 2017 2 commits
  3. 26 Jul, 2017 11 commits
  5. 25 Jul, 2017 6 commits
    • Jason Yellick's avatar
      [FAB-5459] Recompute configmap instead of updating · 6eab9cf6
      Jason Yellick authored 
      

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: default avatarJason Yellick <jyellick@us.ibm.com>
      6eab9cf6
    • Will Lahti's avatar
      [FAB-5391]Prevent concurrent invokes launching cc cont · 2232d0ec
      Will Lahti authored 
      

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: default avatarWill Lahti <wtlahti@us.ibm.com>
      2232d0ec
    • Jay Guo's avatar
      [FAB-5236] Add orderer benchmark tests. · f83e0b3b
      Jay Guo authored 
      

Change-Id: Ib255d0f1601864bdaac9e6e272fa2fdc89b4f76b
Signed-off-by: default avatarJay Guo <guojiannan1101@gmail.com>
      f83e0b3b
    • Gari Singh's avatar
      Merge "[FAB-5353]: Qualify sys. failure vs validation error" · 7a480cec
      Gari Singh authored
      7a480cec
    • Jay Guo's avatar
      [FAB-5236] System channel ID should be configurable · 452c7eb8
      Jay Guo authored 
      

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: default avatarJay Guo <guojiannan1101@gmail.com>
      452c7eb8
    • Jason Yellick's avatar
      [FAB-5416] Remove bad common.Configuration doc · f9922518
      Jason Yellick authored 
      

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: default avatarJason Yellick <jyellick@us.ibm.com>
      f9922518
  7. 24 Jul, 2017 6 commits
  9. 23 Jul, 2017 2 commits
  11. 22 Jul, 2017 3 commits
  13. 21 Jul, 2017 7 commits
  15. 20 Jul, 2017 1 commit
  17. 19 Jul, 2017 2 commits