When chaincode is deployed, it fills the peer debug log with
many megabytes of binary dumps, making it difficult to
troubleshoot through the noise.

Change-Id: I7be1814632f0fda272b10793e7e6413b7d1de0e4
Signed-off-by: denyeart <enyeart@us.ibm.com>

Items() was not setting the type of the chain header properly
as was configured in the inner fields of the template.
Since this code works only for configuration items,
I just set it to HeaderType_CONFIGURATION_ITEM.

Also changed the template_test to accomodate the change.

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

This change-set has removed calls to the txvalidator that were issued right
after the peer (the leader) receives blocks from the orderers. The validator
is now called to validate messages received from the gossip layer. In order
to fix an import cycle, we have introduced the ChaincodeProvider interface
in core/common/ccprovider/ccprovider.go, an implementation and a factory.
This way, code that needs to use functions from the chaincode package
without importing it can simply use (and possibly extend) the
ChaincodeProvider interface and implementation.

Furthermore, this drop has introduced protocol-level message validation for
config transactions that was lacking before.

Change-Id: I5906a6fe3da8410b05b5079dd7f0b9d28d20bb85
Signed-off-by: Alessandro Sorniotti <ale.linux@sopit.net>

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



All parameters are passed to chaincode via environment
variables or as parameters. Default properties are not
picked up from core.yaml. In 1.0 architecture, the peer
no longer builds the chaincode package but only passes it
to docker to deploy (the package is built by CLI or SDK).
In this mode the core.yaml in the Dockerfile will typically
not be available in the peer environment.

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

Rework some text and invoke transaction sample

Change-Id: Ie6927316494cace186fdac4f14e7443e1779c692
Signed-off-by: Binh Q. Nguyen <binhn@us.ibm.com>

This is simply a copy of the SW CSP:
- sw directory -> pkcs11 directory
- swfactory.go -> pkcs11factory.go

Not much changed: pkcs11factory.go uses PKCS11 instead of "Software"
or "SW". And new package name.

The code is currently un-reachable (except by copied tests). Next
set of changes will add
- configuration: probably integrate what Keith did for
  https://gerrit.hyperledger.org/r/#/c/3735/2


- replace (operation at a time) SW operations with PKCS11 operations

Change-Id: I46f35b92be9303e52d66fdbc0962990efb47104e
Signed-off-by: Volodymyr Paprotski <vpaprots@ca.ibm.com>

orderer.template has to be regenerated to include BatchSize

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

Adds the channel create and join process to the bootstrap
process.

Changed from RSA 2048 to ECDSA curve=NIST384p for signing keys.

Fixed typo in orderer base docker compose file for genesismethod.

Fixed issues with genisis block created for BDD.  Regenerated several
proto files.

Removed reference to membersvc from docker compose files.

Added absMaxBytes to Batchsize for genesis block creation.

Change-Id: If077d3725e6edc0ba3dfe2dd6d2cf66ed255592b
Signed-off-by: jeffgarratt <garratt.jeff@gmail.com>

This system chaincode provides ledger structural query APIs such
as GetTransactionByID, GetBlockByHash, etc. Currently the inputs
require a channel name rather using the channel from the -C
parameter. That will change on next iteration when we change the
chaincode invocation to pass the channel name.

For example, to invoke with CLI
peer chaincode query -C "" -n qscc -c '{"Args":["GetTransactionByID","mychannel","txid"]}'

Change-Id: I31da536f5dd72bb73b0444d8ee11b1b6093c136d
Signed-off-by: Binh Q. Nguyen <binhn@us.ibm.com>

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



Replace often used sequences/patterns throughout the tests in the
`kafka` package with wrapper functions.

Change-Id: I5fe3c6a6221b98a17d6867aba0f40404b856bb65
Signed-off-by: Kostas Christidis <kostas@christidis.io>

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



In the `kafka` package, most of the logic that ties everything together
resides in `main.go`. This changeset renames this file to `orderer.go`,
to avoid any connotations with `main` which in Go pretty much implies a
binary. (Bonus points for the new name being a bit more descriptive as
well.)

Change-Id: Ie9b55f7fa081e20cf8affb1cdc8bd1315a216de6
Signed-off-by: Kostas Christidis <kostas@christidis.io>

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



This changeset removes a few shadow variable declarations that have crept
in the `kafka` package.

Change-Id: Ie3a763917b4d6e33320dd2ba037f92fbae8ae078
Signed-off-by: Kostas Christidis <kostas@christidis.io>

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

In FAB-1382 [1] the Deliver API was modified so as to work with a range.
The BDD implementation of Deliver was also modified in that changeset so
as to take an end block of `NEWEST`.

Occasionally, the Kafka orderer will fail on one of these BDD tests
because the Deliver request comes before all the incoming (via
Broadcast) messages have been processed. In that case, the `NEWEST`
value is translated to a lower-numbered block than the expected one.

As an example, consider the case where we send 100 messages to the
orderer, and each block has 10 messages. When we send the Deliver call,
Kafka has processed 90 messages, so it translates NEWEST to 9. Our test
expects NEWEST to be 10 and thus fails.

Until we find an elegant fix for this, I am adding a 1-second sleep
before the Deliver call is invoked on the Kafka cases. This should add
14 seconds to the duration of these tests.

I stress that this is a temporary patch, and I am open to a more elegant
solution, but until then, the default should not be a setup where the
orderer fails occasionally.

[1] https://gerrit.hyperledger.org/r/#/c/3271/



Change-Id: I77a091546e77981838a4b8ee29019178ddf0d49b
Signed-off-by: Kostas Christidis <kostas@christidis.io>

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

In FAB-1612 [1] new configuration keys were introduced on the
`orderer.yaml` file. The ENV vars on the Compose files we use for the
orderer-related BDD tests however were not updated accordingly. As a
result, all tests would run against the default config setting
(read: solo) and the Kafka path would not get tested.

This changeset addresses this issue.

Additionally it:

1. Removes all environment variables from the Compose files when these
match the defaults in `orderer.yaml`. This reverses an earlier take on
the matter. The thinking behind this change is that we don't need to
keep two sets of settings unless absolutely necessary.

2. Formats `orderer.yaml` so that the recently-added lines break at 80
characters, as is the case with the rest of that file.

[1] https://gerrit.hyperledger.org/r/#/c/3879/



Change-Id: I0d1e137bd4a8e523edb7cb6a060c09ff80d31340
Signed-off-by: Kostas Christidis <kostas@christidis.io>

FAB-1505 refactors CouchDB code to be aligned with LevelDB structure.
FAB-1337 applies all ledger tests written for LevelDB against CouchDB.

In order to test the CouchDB refactor,
had to implement FAB-1337 in same changeset to test.

Like most refactors, this changeset touches a lot of files and code,
since it is not feasible to do a partial refactor.

Tests related to versioning and deleting have been commented out,
these will be re-enabled in subsequent changeset when CouchDB
has the support, in order to keep this changeset size more reasonable.

Change-Id: I0d2d6cca89bd0252f6e84317457a9140b3a0d7a5
Signed-off-by: denyeart <enyeart@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>

Gossip leader election module
This commit adds a leader election module which is an autonomous logical unit.
It will be connected into the gossip layer via an implementation of LeaderElectionAdapter
Which will be implemented after this commit.

Change log:
1) Initial commit
2) Rebase
3) Changed comment in test
4) Rephrased a log message
5) Changed comments in algorithm outline

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

In one of the gossip tests we have a test that ensures that all goroutines
 stop after all gossip instances stop.
It sometimes fails because it detects a connection-related goroutine is still
 alive after instances are stopped.

I'm investigating this, but I would rather not have CI fail because of it,
as it's not a show-stopper and doesn't indicate a functionality isn't working,
but only a possible goroutine leak.

I would rather try reproduce the problem or try and figure
out how this can happen offline, and not have this fail CI.

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

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



The chain-config.proto file is misleadingly named, as it contains only
MSP principal things.  The hyphen in the name is also causing problems
with the proto generation for the python bdd, so this should be changed.

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