1. 11 Mar, 2019 1 commit
    • Jason Yellick's avatar
      FAB-14502 Clarify deliver 'Errored' message · c141d798
      Jason Yellick authored
      The deliver service is currently quite ambiguous about the error
      condition when the channel returned by Errored() closes.  This is likely
      because this message could be returned by a peer or orderer.  However,
      in reality, the only time this condition ever occurs is because of a
      consenter error.  In the interest of serviceability, this CR makes the
      error message more specific, making a note that we should handle
      generalizing it if the peer ever implements this function.
      Change-Id: I5c2dfb8fa4ba32c34660b69b5facf90291ee17f3
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
  2. 30 Nov, 2018 1 commit
  3. 14 Nov, 2018 1 commit
  4. 29 Oct, 2018 1 commit
  5. 10 Oct, 2018 1 commit
  6. 26 Sep, 2018 1 commit
    • nirro's avatar
      [FAB-11780] added membership provider to ledger · a02124e4
      nirro authored
      had to refactor a bit, as membership provider creation was
      dependant on collectionStore, which is created per channel,
      therefore membership provider was also created per channel.
      changed it such that we can create a single membership provider
      FAB-11780 - #done
      Change-Id: I2c44ebf00d6eea1fc1d713b3168328f95074c6b5
      Signed-off-by: default avatarnirro <nirro@il.ibm.com>
  7. 23 Sep, 2018 1 commit
    • David Enyeart's avatar
      [FAB-12030] Improve INFO log for block processing · a18f1ea6
      David Enyeart authored
      Previously block processing would log a single statement like this:
      <timestamp> Channel [myc]: Committed block [16] with 1 transaction(s)
      To receive any more information, operators would have to turn
      on debug, which provides an overwhelming amount of information.
      A middle ground is needed, where operators receive the most
      important block processing information (high level steps and timings)
      to help them understand peer health and bottlenecks,
      but without the overwhelming amount of debug noise.
      This change improves the INFO logging per block as follows:
      <timestamp> [myc] Received block [57] from buffer
      <timestamp> [myc] Validated block [57] in 5ms
      <timestamp> [myc] Committed block [57] with 1 transaction(s) in 24ms
                        (state_validation=7ms block_commit=0ms state_commit=16ms)
      This change also:
      - improves core.yaml defaults to pick up some important gossip INFO
      statements (without adding noise)
      - standardizes on the log statement prefix of [channel_name]
      - starts to roll the [channel_name] prefix down to debug statements
        (a full sweep can be done in a next release)
      - standardizes timings to utilize ms (milliseconds)
      Change-Id: I97f3b307a167ce8f445f3cc625bad3b2282b026d
      Signed-off-by: default avatarDavid Enyeart <enyeart@us.ibm.com>
      Signed-off-by: default avataryacovm <yacovm@il.ibm.com>
      Signed-off-by: default avatarmanish <manish.sethi@gmail.com>
  8. 24 Aug, 2018 2 commits
    • manish's avatar
      Ledger-lscc: Implement 'DeployedChaincodeInfoProvider' · aec2ab98
      manish authored
      This CR implements interface 'DeployedChaincodeInfoProvider'
      based on the current logic of how lscc maintains
      chaincode and collection configuration information
      FAB-11563 #done
      Change-Id: I2ca75040e3c219b353c3140d2f326e9bc74898e6
      Signed-off-by: default avatarmanish <manish.sethi@gmail.com>
    • manish's avatar
      Ledger-lscc: Interface for decoupling ledger and lscc · 3d3b4a77
      manish authored
      This CR
      - Introduces an interface 'DeployedChaincodeInfoProvider'
      for decoupling the ledger code from chaincode lifecycle code
      - Declares ledger's dependency on this interface explicitly.
      The intent is that ledger code will use this dependency for
      listening to chaincode lifecycle events and for querying
      the information about the deployed chaicodes
      - Introduces a convenient function in legder that other modules
      can use directly to get information about the chaincodes
      FAB-11562 #done
      Change-Id: I3eb0e798f00ceb18203128fd9da93822fc2bca2b
      Signed-off-by: default avatarmanish <manish.sethi@gmail.com>
  9. 15 Aug, 2018 1 commit
    • Will Lahti's avatar
      FAB-7382 Remove ReadyChan() from Deliver ledgers · a9e8cd71
      Will Lahti authored
      This CR reworks the ledger interfaces and implementations
      used by the Deliver service to remove the ReadyChan() function,
      which has not been used since FAB-7273 was merged. The
      chainSupport struct for the peer is also updated to only
      include the ledger. The file ledger is now returned when
      Reader() is called by the deliver service.
      FAB-7382 #done
      Change-Id: I6d08f30b9093ec3120cdeee749aa51afe54e2cdc
      Signed-off-by: default avatarWill Lahti <wtlahti@us.ibm.com>
  10. 03 Jul, 2018 1 commit
    • Jason Yellick's avatar
      FAB-10825 Make platform latent dependency explicit · 9112ebfb
      Jason Yellick authored
      Many of the assorted 'utils' functions actually reach into the
      core/chaincode/platforms package to determine whether packages are
      valid.  This historically has all been done in a source-coupled way,
      pulling peer details into places it does not belong.  Although these
      'util' functions should be refactored and removed, for the time being,
      we can at least make the dependency on the platforms package explicit,
      but requiring that an instance be passed into these util functions.
      This has quite the ripple throughout the code, but the CR itself should
      be trivial to review.
      Change-Id: I0cc36e2f307474ddba7f6d20028a46f3aa94faf5
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
  11. 25 Jun, 2018 1 commit
    • Will Lahti's avatar
      FAB-10855 Cleanup unsupported capabilities panic msgs · f2c1a47f
      Will Lahti authored
      This CR cleans up the panic messages when unsupported capabilities
      are detected. The messages were seemingly written to include simply
      the channel ID instead of the entire ConfigtxValidator() object.
      This CR also cleans up a few other error messages and a linter problem.
      Change-Id: I337dc6cdecc7c4ab897e414530798e5659bf85e5
      Signed-off-by: default avatarWill Lahti <wtlahti@us.ibm.com>
  12. 16 May, 2018 1 commit
  13. 14 May, 2018 1 commit
  14. 13 May, 2018 1 commit
    • Artem Barger's avatar
      [FAB-9955] Use coll. conf available at endorsement · 44fd7722
      Artem Barger authored
      There is possible data race condition while distributing private data,
      since now we have to support dynamic collections, where it's possible
      that collection config might be updated right after the endorsement,
      therefore in distributor while looking up for collection config from
      collection store we might get updated config which might be not lober
      relevant for the private data in context.
      This commit refactors the distribution flow my actually making use of
      the collection config which is available at the endorsement time,
      which also allows to optimize, since reduces the need to execute
      queries with collection store. Additional since using collection config
      which was available during endorsement allows to elliminate the race
      condition. Addresses comments of code-review: CR-21491.
      Change-Id: I0d3c682a613bf3ae5b46e32230fadf6b12895fdf
      Signed-off-by: default avatarArtem Barger <bartem@il.ibm.com>
  15. 11 May, 2018 1 commit
  16. 08 May, 2018 1 commit
  17. 01 May, 2018 1 commit
  18. 25 Apr, 2018 1 commit
  19. 18 Apr, 2018 1 commit
  20. 26 Mar, 2018 1 commit
  21. 14 Mar, 2018 1 commit
    • Gari Singh's avatar
      [FAB-8870] Return concrete types from constructors · 0cf1830c
      Gari Singh authored
      The contructors for the gRPC client and server were
      actually returning interfaces rather than
      concrete types.  As there was really no use for
      the interfaces in the package, the interfaces
      were removed and concrete types are now public and
      returned from the constructors.
      Additionally, some cleanup on the types as well
      to remove redundant fields.
      Change-Id: I1c82f77aab3419fcde4f04e6a083428b85086bae
      Signed-off-by: default avatarGari Singh <gari.r.singh@gmail.com>
  22. 07 Mar, 2018 1 commit
    • Matthew Sykes's avatar
      [FAB-8660] Operations and PeerSupport interfaces · 580d091a
      Matthew Sykes authored
      This introduces an interface that represents the currently exported
      functions of the peer. An instance of the interface is created during
      package initialization which delegates to the existing functions.
      - References to the peer functions in endorser.Support are replaced with a
        reference to the peer singleton.
      - CreatePeerServer is renamed to the more idiomatic NewPeerServer as it
        is a constructor
      - PeerSupportFactory is removed and an instance of PeerSupport is
        provided to endorser.SupportImpl and scc.ProviderFactory
      Change-Id: I07ae90092be8349bed60686f7b04a5b9ab02382a
      Signed-off-by: default avatarMatthew Sykes <sykesmat@us.ibm.com>
  23. 05 Mar, 2018 2 commits
  24. 24 Jan, 2018 1 commit
  25. 19 Jan, 2018 1 commit
    • Jason Yellick's avatar
      [FAB-7399] Check for uninitialize config state · adf63b1e
      Jason Yellick authored
      The v1.1 peer code added config transaction processing to store the
      channel config in the state database.  This is the more obviously
      correct way to store config, but on upgrade, the state database will not
      already have stored a copy of the config.
      This CR adds back the old config processing code to extract the channel
      config from the config block in the event that it is not stored in the
      Change-Id: Ied88406d92dd8d6d33d45a6d5eb3b05375270905
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
  26. 10 Jan, 2018 1 commit
    • yacovm's avatar
      [FAB-6160] peer deliver refresh AC upon resource update · 81af16ea
      yacovm authored
      When https://gerrit.hyperledger.org/r/#/c/16037/
       is going to be merged,
      the custom ACL is going to reside in the resource config.
      The deliver service in the peer would need a way to re-evaluate clients
      when a resource config has occurred.
      The current code exposes a method to the support of the deliver service
      that returns the sequence of the latest channel config.
      The access control logic in the deliver service, caches this sequence,
      and before sending out a block - it checks if the config has changed,
      and if it did - re-evaluates the policies.
      This change set, simply makes this sequence to be the sum
      of both resource config sequences, and channel config sequences.
      Since both sequences are monotonously increasing, the sum is also
      monotonously increasing, and therefore we can present to the deliver
      service access control logic the sum as the sequence, without
      changing anything else.
      Change-Id: Ib3cc04c51f21598027fb8eae68d04b027184f52f
      Signed-off-by: default avataryacovm <yacovm@il.ibm.com>
  27. 06 Jan, 2018 1 commit
    • Gari Singh's avatar
      [FAB-7633] Cleanup dead comm code · 25225990
      Gari Singh authored
      With FAB-7490, the peer CLI communication code
      was refactored to use the comm.GRPCClient.
      There are a few functions which are no longer
      called in core/peer which have now been
      Additionally, the comm.InitTLSForPeer function
      is no longer needed by any of the main code paths.
      As it was only included in a few tests (but never
      actually executed) , it has been removed as well.
      An additional benefit is that this removes viper
      from the core/comm package as well.
      Change-Id: I0c25f9896dc7caf8cb8d86d6f85ce89270c34b00
      Signed-off-by: default avatarGari Singh <gari.r.singh@gmail.com>
  28. 05 Jan, 2018 2 commits
    • Will Lahti's avatar
      [FAB-7604] Peer deliver unusable when pol. not defined · 5fa00ffc
      Will Lahti authored
      After FAB-7521, the peer deliver service is unusable because the
      BLOCKEVENT policy is not set by default. This CR uses the aclmgmt
      package, which will check for the policy and, if not set, use the
      default value (in this case, channel readers). It also restores the
      behave tests to their previous state to ensure peer deliver remains
      usable by default.
      Change-Id: I46e71853881271539e28a110ce8b81d3bd248d19
      Signed-off-by: default avatarWill Lahti <wtlahti@us.ibm.com>
    • Jason Yellick's avatar
      [FAB-7399] Check for nil resources config · e997f7d4
      Jason Yellick authored
      If the experimental resources tree support is enabled, but the genesis
      block does not contain a seed resources tree, then an error is thrown
      because the config is nil.  This CR simply checks for the nil case, and
      if so, uses an empty resources tree as the seed.
      Change-Id: I7c031d5c450cf9601175fc04a7d2c5355f051b7a
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
  29. 04 Jan, 2018 1 commit
  30. 03 Jan, 2018 1 commit
    • Artem Barger's avatar
      [FAB-7521] Lookup correct policy name · b4a1ec82
      Artem Barger authored
      While reusing deliverer API as a blocks event source at peer we need to
      lookup for correct policy name based on the RSCC resource API definition
      name. This commit adds a factory method which introduces level of
      indirection to allow lookup of correct policy name based on the deliver
      API initialization handler.
      Change-Id: Ib896736793722549f035cca9e0b6a4c871050615
      Signed-off-by: default avatarArtem Barger <bartem@il.ibm.com>
  31. 19 Dec, 2017 1 commit
  32. 08 Dec, 2017 3 commits
  33. 07 Dec, 2017 2 commits
    • Will Lahti's avatar
      [FAB-7049] Expose deliver service on peer · dab82c9f
      Will Lahti authored
      This CR exposes the deliver service on a peer, which will allow clients
      to retrieve blocks using the same mechanism that is available on the
      Change-Id: Iafcbcf32c7a448680a6726ae4cca5fb94832e68b
      Signed-off-by: default avatarWill Lahti <wtlahti@us.ibm.com>
    • manish's avatar
      [FAB-6227] custom processor for resource configs · 67746c36
      manish authored
      This CR introduces a custom transaction processor that processes
      resource config update transactions. Ledger invokes this processor
      for transactions of type CONFIG, and PEER_RESOURCE_UPDATE
      during the validation and commit phase of a block processing.
      For CONFIG, this simply stores the config in the statedb.
      For PEER_RESOURCE_UPDATE - In a normal course, this validates the transaction
      against the current resource bundle, computes the full configuration, and
      stores the full configuration if the transaction is found valid.
      However, during initialization of ledger (i.e., either the ledger is being
      created from the genesis block or the ledger is synching the state with the
      blockchain during start up - possibly prommpted by a peer crash last time),
      the full config is computed using the most recent configs from statedb, if found.
      Change-Id: Ia18432e8cede18d378b820c13019acc2995197a4
      Signed-off-by: default avatarmanish <manish.sethi@gmail.com>
  34. 06 Dec, 2017 1 commit