1. 16 May, 2018 1 commit
    • Will Lahti's avatar
      [FAB-10132] Align outlier peer CLI success msg log lvl · fab5d976
      Will Lahti authored
      
      
      The "peer channel fetch" and "peer chaincode install" commands
      currently log their success output message at the debug level.
      This can make certain integration/e2e tests fail unexpectedly
      if the log level is set to any other level.
      
      It seems natural that the logged success message should be at
      the info level.
      
      Change-Id: I8ad961a5b55b7a353f329218d9090457ed1bf0be
      Signed-off-by: default avatarWill Lahti <wtlahti@us.ibm.com>
      fab5d976
  2. 04 Jan, 2018 1 commit
    • Gari Singh's avatar
      [FAB-7490] Mutual TLS support for CLI · fcbbbe7c
      Gari Singh authored
      
      
      The CLI was not working properly with mutual TLS
      enabled.  In order to add support for client
      certficates, the code needed to be partially
      refactored by adding peer and orderer client
      instances.  This code should be useful in the
      future as part of any additional CLI rework.
      
      Change-Id: Ifa19c26bf3aff887c5279a8f721e0425ec49732e
      Signed-off-by: default avatarGari Singh <gari.r.singh@gmail.com>
      fcbbbe7c
  3. 18 Jul, 2017 1 commit
    • Jason Yellick's avatar
      [FAB-5365] Fix bad error in peer CLI Deliver · 22e12995
      Jason Yellick authored
      
      
      The peer CLI currently attempts to print the error status returned by
      the orderer's Deliver gRPC method.  However, the log statement
      inappropriately uses the '%T' modifier, and prints the type of the
      status, not the actual status code inside it.  Consequently, all deliver
      errors read the same uninformative error message:
      
          Got Status:*orderer.DeliverResponse_Status
      
      This CR fixes this log statement to include the status code instead, and
      additionally enhances the other error messages with pertitent
      information.
      
      Change-Id: I5a3e1dec574bfab178550cf67bc96a66f1896d5b
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      22e12995
  4. 05 Jun, 2017 1 commit
  5. 01 Jun, 2017 1 commit
    • Jason Yellick's avatar
      [FAB-4264] Fix peer channel fetch command · 389ff3e0
      Jason Yellick authored
      
      
      The peer channel fetch command has multiple problems.
      
      1. It claims to fetch the configuration block, but actually fetches only
      the genesis block.
      
      2. The seekHelper in the deliver code claims to accept a seek position
      start index, and returns one block, but in fact always seeks from oldest
      to maxuint64 returning an infinite number of blocks.
      
      3. The command outputs to a fixed filename (varying only by channel
      name).
      
      This CR fixes all three of these problems.
      
      Change-Id: Ibd6c041f88f736b1948a12d81ee49ce6fe42538a
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      389ff3e0
  6. 24 May, 2017 1 commit
  7. 16 May, 2017 1 commit
    • YACOVM's avatar
      [FAB-3941] Fix UT failure of port collision · a0c3b954
      YACOVM authored
      
      
      This commit fixes the following possible failure:
      
      panic: listen tcp 127.0.0.1:7050: bind: address already in use [recovered]
      panic: listen tcp 127.0.0.1:7050: bind: address already in use
      
      goroutine 167 [running]:
      panic(0x95a0c0, 0xc4203993b0)
      /opt/go/src/runtime/panic.go:500 +0x1a1
      testing.tRunner.func1(0xc420097200)
      /opt/go/src/testing/testing.go:579 +0x25d
      panic(0x95a0c0, 0xc4203993b0)
      /opt/go/src/runtime/panic.go:458 +0x243
      github.com/hyperledger/fabric/peer/channel.newOrderer
      /opt/gopath/src/github.com/hyperledger/fabric/peer/channel/create_test.go:53
      github.com/hyperledger/fabric/peer/channel.TestCreateChainWithTimeoutErr
      /opt/gopath/src/github.com/hyperledger/fabric/peer/channel/create_test.go:258
      testing.tRunner(0xc420097200, 0xa3cf48)
      /opt/go/src/testing/testing.go:610 +0x81
      created by testing.(*T).Run
      /opt/go/src/testing/testing.go:646 +0x2ec
      FAIL github.com/hyperledger/fabric/peer/channel 3.168s
      error: exit status 1
      panic: EOF
      
      I think this happens because the client doesn't close the connection
      and the server port remains in TIME_WAIT and since we have 2 tests that bind
      to the same port, the one that runs the 2nd time - fails.
      
      The easiest way to solve this is simply by changing the port numbers
      that are used in the test, but I simply added a connection close
      to the getGenesisBlock method.
      
      Change-Id: Ia08c3d8d10a8e01cf96ea2789b4d236921b850b5
      Signed-off-by: default avatarYacov Manevich <yacovm@il.ibm.com>
      a0c3b954
  8. 11 May, 2017 1 commit
    • Nao Nishijima's avatar
      [FAB-2982] Add timeout option to peer channel cmd · 290b46f8
      Nao Nishijima authored
      
      
      These patches add timeout option to "peer channel create" and
      "peer channel fetchconfig".
      
      This bug(FAB-2982) happens because peer tries to get the genesis block
      before orderer start its channel. Since the execution time of channel
      initialization depends on the environment, users should control the
      procedure of channel creation with "-t" option.
      
      Change-Id: Ia3f2295b88ec04e517c4cfd21b36fe3309d48247
      Signed-off-by: default avatarNao Nishijima <Nao.nishijima@hal.hitachi.com>
      290b46f8
  9. 30 Apr, 2017 1 commit
  10. 06 Mar, 2017 1 commit
  11. 21 Feb, 2017 1 commit
    • Alessandro Sorniotti's avatar
      [FAB-1392] - Use bytes for headers · 011cd41b
      Alessandro Sorniotti authored
      
      
      This change set ensures that the protobuf representation for headers be in
      bytes. This makes sure that if ever protobuf marshalling is non-deterministic,
      we do not have problems because whenever we hash a header, we do that over
      the serialized version we receive.
      
      Change-Id: I838e0d5dec2f79f88fab63d92bdfb51d92c2f069
      Signed-off-by: default avatarAlessandro Sorniotti <ale.linux@sopit.net>
      011cd41b
  12. 11 Feb, 2017 2 commits
  13. 15 Jan, 2017 1 commit
    • Srinivasan Muralidharan's avatar
      FAB-1547 initial create/join chain support · a93135b1
      Srinivasan Muralidharan authored
      https://jira.hyperledger.org/browse/FAB-1547
      
      With this change the fabric has basic support for create / join
      chain begun with the implementation of CSCC (configuraton system
      chaincode) in https://jira.hyperledger.org/browse/FAB-1022.
      
      Some todos remain for follow up CRs
        . docker based commands to channel-setup.md
        . CONFIGURATION_TRANSACTION validation - https://jira.hyperledger.org/browse/FAB-1639
        . further MSP integration (still uses default MSP)
        . absorption of deliver client management into gossip later - https://jira.hyperledger.org/browse/FAB-1580
        . adding specific configuration items to channel create - https://jira.hyperledger.org/browse/FAB-1642
      
      
      
      Steps to test chain create / join below. All commands assume shell
      in "fabric/" directory.
      
      Vagrant window 1 - start orderer
        cd orderer
        ORDERER_GENERAL_LOGLEVEL=debug ./orderer
      
      Vagrant window 2 - ask orderer to create a chain
        cd peer
        peer channel create -c myc1
      
        #on successful creation, a genesis block myc1.block is saved
        #in the same directory
      
      Vagrant window 3 - start the peer without **TEST_CHAINID**
                         (basically in a "chainless" mode)
      
        #to start with a clean env do "rm -rf /var/hyperledger/*"
        cd peer
        peer node start --peer-defaultchain=false
      
        #in "--peer-defaultchain=false" mode the peer has to join
        #chains to create leader and do transactions. It does not
        #have a default chain or ledger (the **TEST_CHAINID** chain)
      
      Vagrant window 4 - ask peer to join a chain
        cd peer
        peer channel join -b myc1.block
      
      At this point we can issue transactions
      
      Vagrant window 2 - deploy a chaincode to myc1
        cd peer
        peer chaincode deploy -C myc1 -n mycc -p github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02 -c '{"Args":["init","a","100","b","200"]}'
      
        #note the use of "-C myc1"
        #wait for 10 secs or so
      
      Vagrant window 2 - query chaincode
        cd peer
        peer chaincode query -C myc1 -n mycc -c '{"Args":["query","a"]}'
      
      Change-Id: I7d1d04e8a207eb57597a1e6eb8b986e1080e7811
      Signed-off-by: default avatarSrinivasan Muralidharan <muralisr@us.ibm.com>
      a93135b1
  14. 11 Jan, 2017 1 commit
    • Jason Yellick's avatar
      [FAB-1573] Make deliver API signable · 1bf61907
      Jason Yellick authored
      https://jira.hyperledger.org/browse/FAB-1573
      
      
      
      This changeset modifies the Deliver API to accept an Envelope of type
      DELIVER_SEEK_INFO instead of a standard SeekInfo message.  The Envelope
      embeds a SeekInfo as well as the bits necessary to construct a
      non-replayable signature.
      
      This unfortunately breaks the API, but it seems better to fix it now
      than to wait until there are more dependencies.
      
      The alternative was to invent yet another signing scheme, which seemed
      like it would be equally as much work on the consumer side with ongoing
      messiness.
      
      Change-Id: I3e8a759d33f68cb6a69f5242440136da730f0396
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      1bf61907
  15. 19 Dec, 2016 1 commit
    • Jason Yellick's avatar
      [FAB-1382] Remove window from Deliver API · 785eaf04
      Jason Yellick authored
      https://jira.hyperledger.org/browse/FAB-1382
      
      
      
      The deliver API currently works on a windowing concept.  Because of the
      HTTP2/gRPC internal windowing, this additional layer of windowing is
      unnecessary.
      
      This changeset removes the notion of a Window from Deliver and instead
      replaces it with a start and stop position specification.  To receive
      blocks indefinitely (replicating the old behavior with ACKs) the end
      position may be specified as MAX_UINT64.
      
      This changeset has an unfortunately high amount of ripple, and required
      extensive rework in the bdd tests, but the overall changeset is a
      simplification.
      
      Change-Id: I5095da82ab1f6d892b0112cdb9848842529936d9
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      785eaf04
  16. 15 Dec, 2016 1 commit
    • Kostas Christidis's avatar
      [FAB-1364] Switch to provisional bootstrapper · 71a3389f
      Kostas Christidis authored
      https://jira.hyperledger.org/browse/FAB-1364
      
      
      
      All consenters read several of their config settings (think sharedconfig)
      from the genesis block that is generated by a bootstrapper. The only
      bootstrapper available so far is the static one. However, when testing we
      need to be able to modify several of these config values on the fly.
      
      Therefore the bootstrapper should be able to read a config object (which
      is itself created by reading the orderer.yaml file and -if set- its
      associated ENV vars).
      
      An example of that would be the KafkaBrokers value. For unit tests the
      "right" value is "127.0.0.1:9092", whereas for the current Docker
      Compose-based BDD tests the right value is "kafka0:9092".
      
      Since this bootstrapper is no longer static, renaming the package seemed
      appropriate. For production we will need to introduce file-based
      bootstrapper that reads the genesis block created by the genesis block
      tool.
      
      This changeset allows the bootstrapper to generate the appropriate
      genesis blocks (with their own custom keys) for all know consenters
      types: solo, kafka, sbft (though sbft for now just short-circuits to the
      solo case).
      
      The new bootstrapper is built in a way that makes further extensions
      easier, and minimizes code duplication by creating the appropriate
      structs and doing the necessary embeddings.
      
      The test that inspected the block's Data field was removed. It was a
      tautological test, serving no good purpose, and was also hard to
      maintain.
      
      Finally, this changeset updates the bootstrap helper signature by
      removing the error return; while the error return can be useful if the
      expectation is that the caller will be able to resort to a different
      bootstrapper if the first one fails, etc. one could that this amount of
      flexibility is unnecessary, and complicates the code needlessly. The
      bootstrapper should simply panic if the wrong settings have been passed
      to it, and the user should read the fine manual.
      
      Change-Id: I6aef9b19dbf9a39652d2d6b3ccbefc794e3001df
      Signed-off-by: default avatarKostas Christidis <kostas@christidis.io>
      71a3389f
  17. 12 Dec, 2016 1 commit
    • Jason Yellick's avatar
      [FAB-998] Add new-chain sample client · 1093492c
      Jason Yellick authored
      https://jira.hyperledger.org/browse/FAB-998
      
      
      
      This changeset introduces a sample client that sends a single envelope
      via the broadcast RPC to the ordering service. This envelope contains a
      configuration envelope that calls for the creation of a new chain.
      
      The client is invoked as follows:
      
      $ broadcast_config -cmd new-chain -chainID newChainID
      
      As is the case with the bd_counter sample client, the user can also set
      the logging level (-loglevel) and the address of the RPC server
      (-server).  The user may also set the backing creation policy
      (-creationPolicy).
      
      This changeset also adds chainID support for the deliver_stdout and the
      broadcast_timestamp sample clients.
      
      Change-Id: I782eb77c45f5c8d91c75c4440e47a20ab76a560e
      Signed-off-by: default avatarKostas Christidis <kostas@christidis.io>
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      1093492c
  18. 02 Dec, 2016 1 commit
    • Jason Yellick's avatar
      Rename orderer/config to orderer/localconfig · 8e97791a
      Jason Yellick authored
      
      
      The orderer service has two different types of configuration,
      configuration which is local to the process (such as buffer sizes, and
      backing structures like ledger type and location) as well as global
      configuration which must be the same across nodes, such as the consensus
      type and batch size.
      
      Today, this information is all stored in one local config file
      (orderer.yaml) but this needs to change.  As a first step to
      differentiate between config which is local and which is shared, this
      changeset renames the current yaml config mechanism to be localconfig
      with the expectation that a sharedconfig package will be created in the
      future.
      
      Change-Id: I72298554600d8dc0d0c441e47fe9ab9c801e6aab
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      8e97791a
  19. 22 Nov, 2016 1 commit
    • Jason Yellick's avatar
      Define a static TestChainID · 3a55da0a
      Jason Yellick authored
      
      
      As multichain support comes online, the randomly generated chainID in
      the static bootstrapper causes problems.  This is because the clients
      must know the chainID ahead of time before submitting transactions.
      This has also caused problems for SBFT testing as multiple processes
      must agree on the system chain ID.
      
      This changeset defines a static TestChainID for static bootstrapping and
      fixes the assorted sample clients to utilize this TestChainID.
      
      Change-Id: I73457faea4b29fc6f8f62a196f419fcc66cb36ed
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      3a55da0a
  20. 10 Nov, 2016 1 commit
    • Jason Yellick's avatar
      Move ab Status codes to common · 492f2ade
      Jason Yellick authored
      
      
      In order to have consistent error reporting across the fabric, it has
      been decided to use standard HTTP status codes.  These were defined in
      the orderer ab.proto, but have wider applicability.
      
      This changeset removes the Status message from ab.proto and moves it to
      common.proto.
      
      Change-Id: I511bcdd0442e9b06daba678763c87f32478377f4
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      492f2ade
  21. 07 Nov, 2016 1 commit
    • Jason Yellick's avatar
      Merge orderer protos into main protos · c0ba3c23
      Jason Yellick authored
      
      
      This commit begins the work of codifying a single set of common protos
      which both the orderer and fabric access, plus a specific set of orderer
      protos which are necessary to interact with the ordering service.  In
      the future, it is expected that the peer protos will go into their own
      directory (importing the common protos).
      
      This changeset looks a little scarier than it is, because the effects of
      changing these paths are far reaching indeed, but should be relatively
      easy to review.
      
      Note that this is the first ever cross-directory-dependent protos
      included in the fabric.  This means the generation incantations change a
      little.  Instead of importing the directory which contains the protos,
      instead, a common root directory must be picked.
      
      The compile_protos.sh has been changed to look for .protoroot files and
      if present use this as the proto compilation root, rather than the
      directory containing the proto.
      
      Change-Id: I619ea2c50ffd450640dafbddc7d7e5f34f809f3b
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      c0ba3c23
  22. 01 Nov, 2016 1 commit
    • Jason Yellick's avatar
      Update to new proposed block format · ec38c35c
      Jason Yellick authored
      This changeset updates ab.proto to use the block format discussed in
      JIRA issue https://jira.hyperledger.org/browse/FAB-384
      
      
      
      It more closely mirrors the batch format proposed by Simon in the SBFT
      work as well as the time tested bitcoin block structure.
      
      Note that the block is split into three pieces, Header, Data, and
      Metadata.  This makes the clear distinction that the Headers chain
      together, and the Headers have a reference to the hash of the Data.
      Therefore the Metadata section can be used for storage of information
      which should not be hashed, such as signature collections.  See the JIRA
      issue for more details.
      
      Assuming this block format is accepted, it should be removed from
      ab.proto and pushed into the fabric.proto / fabric_next.proto.
      
      Change-Id: I9e9f5afa10e29258ba5ad2a8c536a781e765664f
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      ec38c35c
  23. 27 Oct, 2016 1 commit
  24. 05 Oct, 2016 1 commit
    • Jason Yellick's avatar
      Add orderer config mechanism · 60e4e45e
      Jason Yellick authored
      This changeset adds an orderer.yaml config file which
      specifies the defaults which were previously hardcoded.
      
      It also correspondingly removes the hardcoded defaults and
      utilizes the configuration in those places.
      
      It resolves https://jira.hyperledger.org/browse/FAB-386
      
      This configuration is being done using a variant of Viper's
      Unmarshal.  In newer versions of Viper there is a new
      function UnmarshalExact which throws errors when Unmarshaling
      encounters config fields which are unexpected.
      
      However, there are two outstanding bugs around this Viper
      feature which affect us and do not make pulling the newer code
      worthwhile at this point.
      
      1. Unmarshaling does not appropriately support time durations
      
      https://github.com/spf13/viper/issues/105
      https://github.com/spf13/viper/pull/205
      
      2. Unmarshaling does not correctly handle env overrides of
      nested config parameters
      
      https://github.com/spf13/viper/issues/160
      
      
      
      This changeset includes a stand-in implementation of UnmarshalExact
      which does not suffer from these Viper bugs.  These workarounds
      should be removed once fixes are pushed upstream.
      
      Committing to reclaim this commit after a little Gerrit accident
      
      Change-Id: I931b955b0d8fdaacb240a1b480eb695109774e38
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      60e4e45e
  25. 30 Aug, 2016 1 commit