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: Will Lahti <wtlahti@us.ibm.com>

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: Gari Singh <gari.r.singh@gmail.com>

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: Jason Yellick <jyellick@us.ibm.com>

In peer/channel  package replaced "fmt.Println"

and "fmt.Printf" with  proper logging for files

channel.go
deliverclient.go
join.go
list.go

Change-Id: I820cc977e6745e4e9ce4f66e9d32f2cf6598bc58
Signed-off-by: Dinesh Kumar <dinesh.kumar@itpeoplecorp.com>

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: Jason Yellick <jyellick@us.ibm.com>

The master is somehow broken via
14:43:38 peer/channel/deliverclient.go:118: not enough arguments in call to InitCmdFactory

Change-Id: If00de7e83542f14440f20eb86f6579efa4dc9ff0
Signed-off-by: Yacov Manevich <yacovm@il.ibm.com>

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: Yacov Manevich <yacovm@il.ibm.com>

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: Nao Nishijima <Nao.nishijima@hal.hitachi.com>

remove unused variables and functions found by unused

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

https://jira.hyperledger.org/browse/FAB-2665



CLI and peer were not signing delivery client. This is needed
for stricter orderer changes coming in.

Change-Id: I3b09a688f5c6592cd8f15424b06bd21b85e4f313
Signed-off-by: Srinivasan Muralidharan <muralisr@us.ibm.com>

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: Alessandro Sorniotti <ale.linux@sopit.net>

https://jira.hyperledger.org/browse/FAB-2033



The user facing documentation refers to channels, but the vast majority
of the fabric code refers to chains.  This CR switches the protos to
refer to channels as they are generally the interface between the user
and fabric code.

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

https://jira.hyperledger.org/browse/FAB-2030

According to the proto style guide, fields should be lower_underscored
which generally converts nicely to golang as LowerUnderscored.  However,
for certain cases, like chaincode_id, this converts to ChaincodeId
rather than as desired to ChaincodeID.  This change updates the
problematic fields to use the correct proto style, and updates the
golang to expect the appropriate (although odd) output.

Note, per the proto devs, https://github.com/golang/protobuf/issues/53
there is no intent to modify the protoc generation to attempt to produce
upper case ID API, etc.

Still, the odd golang results seem worth following the style guide.

Note, this CR also changes chainID to channel_id as these lines were
already being affected and a community apparently came to a decision
that the world channel is preferable to the word chain.

https://jira.hyperledger.org/browse/FAB-2033



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

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: Srinivasan Muralidharan <muralisr@us.ibm.com>

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: Jason Yellick <jyellick@us.ibm.com>

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: Jason Yellick <jyellick@us.ibm.com>

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: Kostas Christidis <kostas@christidis.io>

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: Kostas Christidis <kostas@christidis.io>
Signed-off-by: Jason Yellick <jyellick@us.ibm.com>

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: Jason Yellick <jyellick@us.ibm.com>

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: Jason Yellick <jyellick@us.ibm.com>

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: Jason Yellick <jyellick@us.ibm.com>

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: Jason Yellick <jyellick@us.ibm.com>

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: Jason Yellick <jyellick@us.ibm.com>

With the completion of the broadcast filtering framework, the
configuration manager, the policy manager, and the genesis block
creation, it is now possible for the orderer to filter and apply
configuration received over the wire as a transaction.  This changeset
adds that functionality for the solo ordering service.

https://jira.hyperledger.org/browse/FAB-593



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

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: Jason Yellick <jyellick@us.ibm.com>

Change-Id: I1bf2c44e5dc77a13b4749ea82c1df7fed618fd2f
Signed-off-by: jyellick <jyellick@us.ibm.com>