github.com/leonlxy/hyperledger@v1.0.0-alpha.0.20170427033203-34922035d248/bddtests/features/bootstrap.feature (about)

     1  #
     2  # Test Bootstrap function
     3  #
     4  # Tags that can be used and will affect test internals:
     5  #  @doNotDecompose will NOT decompose the named compose_yaml after scenario ends.  Useful for setting up environment and reviewing after scenario.
     6  #
     7  #  @generateDocs will generate documentation for the scenario that can be used for both verification and comprehension.
     8  #
     9  
    10  @bootstrap
    11  Feature: Bootstrap
    12    As a blockchain entrepreneur
    13    I want to bootstrap a new blockchain network
    14  
    15  #    @doNotDecompose
    16      @generateDocs
    17    Scenario Outline: Bootstrap a development network with 4 peers (2 orgs)  and 1 orderer (1 org), each having a single independent root of trust (No fabric-ca, just openssl)
    18      #creates 1 self-signed key/cert pair per orderer organization
    19      Given the orderer network has organizations:
    20        | Organization  |   Readers  | Writers  | Admins  |
    21        | ordererOrg0   |    member  |  member  |  admin  |
    22  
    23      And user requests role of orderer admin by creating a key and csr for orderer and acquires signed certificate from organization:
    24        | User           | Orderer  | Organization  |
    25        | orderer0Signer | orderer0 | ordererOrg0   |
    26        | orderer1Signer | orderer1 | ordererOrg0   |
    27        | orderer2Signer | orderer2 | ordererOrg0   |
    28  
    29  
    30      # Rolenames : MspPrincipal.proto
    31      And the peer network has organizations:
    32        | Organization  |  Readers  | Writers  | Admins  |
    33        |  peerOrg0     |   member  |  member  |  admin  |
    34        |  peerOrg1     |   member  |  member  |  admin  |
    35  #      |  peerOrg2     |   member  |  member  |  admin  |
    36  
    37  
    38  
    39      And a ordererBootstrapAdmin is identified and given access to all public certificates and orderer node info
    40  
    41      And the ordererBootstrapAdmin creates a cert alias "bootstrapCertAlias" for orderer network bootstrap purposes for organizations
    42          | Organization     |
    43          |  ordererOrg0     |
    44  
    45      And the ordererBootstrapAdmin generates a GUUID to identify the orderer system chain and refer to it by name as "OrdererSystemChainId"
    46  
    47      And the ordererBootstrapAdmin creates a consortium "consortium1" (network name) for peer orgs who wish to form a network:
    48        | Organization  |
    49        |  peerOrg0     |
    50        |  peerOrg1     |
    51  #      |  peerOrg2     |
    52  
    53      # Order info includes orderer admin/orderer information and address (host:port) from previous steps
    54      # Only the peer organizations can vary.
    55      And the ordererBootstrapAdmin using cert alias "bootstrapCertAlias" creates the genesis block "ordererGenesisBlock" for chain "OrdererSystemChainId" for network config policy "<PolicyType>" and consensus "<ConsensusType>" using consortiums:
    56        |   Consortium    |
    57        |  consortium1    |
    58  
    59  
    60      And the orderer admins inspect and approve the genesis block for chain "OrdererSystemChainId"
    61  
    62      # to be used for setting the orderer genesis block path parameter in composition
    63      And the orderer admins use the genesis block for chain "OrdererSystemChainId" to configure orderers
    64  
    65      # We now have an orderer network with NO peers.  Now need to configure and start the peer network
    66      # This can be currently automated through folder creation of the proper form and placing PEMs.
    67      And user requests role for peer by creating a key and csr for peer and acquires signed certificate from organization:
    68          | User            | Peer     | Organization  |AliasSavedUnder|
    69          | peer0Signer     | peer0    | peerOrg0      |               |
    70          | peer1Signer     | peer1    | peerOrg0      |               |
    71          | peer2Signer     | peer2    | peerOrg1      |               |
    72          | peer3Signer     | peer3    | peerOrg1      |               |
    73          | peer0Admin      | peer0    | peerOrg0      |peer-admin-cert|
    74          | peer1Admin      | peer1    | peerOrg0      |peer-admin-cert|
    75          | peer2Admin      | peer2    | peerOrg1      |peer-admin-cert|
    76          | peer3Admin      | peer3    | peerOrg1      |peer-admin-cert|
    77  
    78  
    79      And we compose "<ComposeFile>"
    80  
    81      # Sleep as to allow system up time
    82      And I wait "<SystemUpWaitTime>" seconds
    83  
    84      And the following application developers are defined for peer organizations and each saves their cert as alias
    85        | Developer       | Consortium     | Organization  |  AliasSavedUnder   |
    86        | dev0Org0        | consortium1    |  peerOrg0     |    dev0Org0App1    |
    87        | dev0Org1        | consortium1    |  peerOrg1     |    dev0Org1App1    |
    88  
    89      # Need Consortium MSP info and
    90      # need to add the ChannelWriters ConfigItem (using ChannelWriters ref name),
    91      # ChannelReaders ConfigItem (using ChannelReaders ref name)AnchorPeers ConfigItem
    92      # and the ChaincodeLifecyclePolicy Config Item
    93      # NOTE: Template1 will simply hold refs to peer orgs that can create in this channel at the moment
    94      And the user "dev0Org0" creates a peer template "template1" with chaincode deployment policy using consortium "consortium1" and peer organizations:
    95        | Organization  |
    96        |  peerOrg0     |
    97        |  peerOrg1     |
    98  
    99      And the user "dev0Org0" creates an peer anchor set "anchors1" for channel "com.acme.blockchain.jdoe.Channel1" for orgs:
   100        | User            | Peer     | Organization  |
   101        | peer0Signer     | peer0    | peerOrg0      |
   102        | peer2Signer     | peer2    | peerOrg1      |
   103  
   104      # TODO: grab the peer orgs from template1 and put into Murali's MSP info SCIs.
   105      # Entry point for creating a channel from existing templates
   106      And the user "dev0Org0" creates a ConfigUpdateEnvelope "createChannelConfigUpdate1"
   107          | ChannelID                          | Template     | Consortium    | Anchors  |
   108          | com.acme.blockchain.jdoe.Channel1  | template1    | consortium1   | anchors1 |
   109  
   110      And the user "dev0Org0" collects signatures for ConfigUpdateEnvelope "createChannelConfigUpdate1" from developers:
   111        |   Developer     |    Cert Alias    |
   112        |  dev0Org0       |   dev0Org0App1   |
   113        |  dev0Org1       |   dev0Org1App1   |
   114  
   115      And the user "dev0Org0" creates a ConfigUpdate Tx "configUpdateTx1" using cert alias "dev0Org0App1" using signed ConfigUpdateEnvelope "createChannelConfigUpdate1"
   116  
   117      And the user "dev0Org0" using cert alias "dev0Org0App1" broadcasts ConfigUpdate Tx "configUpdateTx1" to orderer "<orderer0>" to create channel "com.acme.blockchain.jdoe.Channel1"
   118  
   119      # Sleep as the deliver takes a bit to have the first block ready
   120      And I wait "<BroadcastWaitTime>" seconds
   121  
   122      When user "dev0Org0" using cert alias "dev0Org0App1" connects to deliver function on orderer "<orderer0>"
   123      And user "dev0Org0" sends deliver a seek request on orderer "<orderer0>" with properties:
   124        | ChainId                               | Start |  End    |
   125        | com.acme.blockchain.jdoe.Channel1     |   0   |  0      |
   126  
   127      Then user "dev0Org0" should get a delivery "genesisBlockForMyNewChannel" from "<orderer0>" of "1" blocks with "1" messages within "1" seconds
   128  
   129      Given user "dev0Org0" gives "genesisBlockForMyNewChannel" to user "dev0Org1"
   130  
   131      Given user "dev0Org0" gives "genesisBlockForMyNewChannel" to user "peer0Admin"
   132      Given user "dev0Org0" gives "genesisBlockForMyNewChannel" to user "peer1Admin"
   133  
   134  
   135      # This is entry point for joining an existing channel
   136      When user "peer0Admin" using cert alias "peer-admin-cert" requests to join channel using genesis block "genesisBlockForMyNewChannel" on peers with result "joinChannelResult"
   137        | Peer       |
   138        | peer0      |
   139  
   140      Then user "peer0Admin" expects result code for "joinChannelResult" of "200" from peers:
   141        | Peer       |
   142        | peer0      |
   143  
   144      When user "peer1Admin" using cert alias "peer-admin-cert" requests to join channel using genesis block "genesisBlockForMyNewChannel" on peers with result "joinChannelResult"
   145        | Peer       |
   146        | peer1      |
   147  
   148      Then user "peer1Admin" expects result code for "joinChannelResult" of "200" from peers:
   149        | Peer       |
   150        | peer1      |
   151  
   152      Given user "dev0Org1" gives "genesisBlockForMyNewChannel" to user "peer2Admin"
   153      Given user "dev0Org1" gives "genesisBlockForMyNewChannel" to user "peer3Admin"
   154  
   155      When user "peer2Admin" using cert alias "peer-admin-cert" requests to join channel using genesis block "genesisBlockForMyNewChannel" on peers with result "joinChannelResult"
   156        | Peer       |
   157        | peer2      |
   158  
   159      Then user "peer2Admin" expects result code for "joinChannelResult" of "200" from peers:
   160        | Peer       |
   161        | peer2      |
   162  
   163      When user "peer3Admin" using cert alias "peer-admin-cert" requests to join channel using genesis block "genesisBlockForMyNewChannel" on peers with result "joinChannelResult"
   164        | Peer       |
   165        | peer3      |
   166  
   167      Then user "peer3Admin" expects result code for "joinChannelResult" of "200" from peers:
   168        | Peer       |
   169        | peer3      |
   170  
   171      # Entry point for invoking on an existing channel
   172      When user "peer0Admin" creates a chaincode spec "cc_spec" with name "example02" of type "GOLANG" for chaincode "github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02" with args
   173        | funcName | arg1 |  arg2 | arg3 | arg4 |
   174        |   init   |  a   |  100  |  b   |  200 |
   175  
   176      # Under the covers, create a deployment spec, etc.
   177      And user "peer0Admin" using cert alias "peer-admin-cert" creates a install proposal "installProposal1" for channel "com.acme.blockchain.jdoe.Channel1" using chaincode spec "cc_spec"
   178  
   179      And user "peer0Admin" using cert alias "peer-admin-cert" sends proposal "installProposal1" to endorsers with timeout of "90" seconds with proposal responses "installProposalResponses":
   180          | Endorser |
   181          | peer0    |
   182  
   183      Then user "peer0Admin" expects proposal responses "installProposalResponses" with status "200" from endorsers:
   184          | Endorser |
   185          | peer0    |
   186  
   187      Given user "peer0Admin" gives "cc_spec" to user "peer2Admin"
   188  
   189      # Under the covers, create a deployment spec, etc.
   190      When user "peer2Admin" using cert alias "peer-admin-cert" creates a install proposal "installProposal1" for channel "com.acme.blockchain.jdoe.Channel1" using chaincode spec "cc_spec"
   191  
   192      And user "peer2Admin" using cert alias "peer-admin-cert" sends proposal "installProposal1" to endorsers with timeout of "90" seconds with proposal responses "installProposalResponses":
   193        | Endorser |
   194          | peer2    |
   195  
   196      Then user "peer2Admin" expects proposal responses "installProposalResponses" with status "200" from endorsers:
   197        | Endorser |
   198          | peer2    |
   199  
   200  
   201      Given user "peer0Admin" gives "cc_spec" to user "dev0Org0"
   202  
   203      # Under the covers, create a deployment spec, etc.
   204      When user "dev0Org0" using cert alias "dev0Org0App1" creates a instantiate proposal "instantiateProposal1" for channel "com.acme.blockchain.jdoe.Channel1" using chaincode spec "cc_spec"
   205  
   206      And user "dev0Org0" using cert alias "dev0Org0App1" sends proposal "instantiateProposal1" to endorsers with timeout of "90" seconds with proposal responses "instantiateProposalResponses":
   207        | Endorser |
   208        | peer0    |
   209        | peer2    |
   210  
   211  
   212      Then user "dev0Org0" expects proposal responses "instantiateProposalResponses" with status "200" from endorsers:
   213        | Endorser |
   214        | peer0    |
   215        | peer2    |
   216  
   217      And user "dev0Org0" expects proposal responses "instantiateProposalResponses" each have the same value from endorsers:
   218        | Endorser |
   219        | peer0    |
   220        | peer2    |
   221  
   222      When the user "dev0Org0" creates transaction "instantiateTx1" from proposal "instantiateProposal1" and proposal responses "instantiateProposalResponses" for channel "com.acme.blockchain.jdoe.Channel1"
   223  
   224      And the user "dev0Org0" broadcasts transaction "instantiateTx1" to orderer "<orderer1>" on channel "com.acme.blockchain.jdoe.Channel1"
   225  
   226      # Sleep as the deliver takes a bit to have the first block ready
   227      And I wait "2" seconds
   228  
   229      And user "dev0Org0" sends deliver a seek request on orderer "<orderer0>" with properties:
   230          | ChainId                               |   Start    |  End    |
   231          | com.acme.blockchain.jdoe.Channel1     |   1   |  1      |
   232  
   233      Then user "dev0Org0" should get a delivery "deliveredInstantiateTx1Block" from "<orderer0>" of "1" blocks with "1" messages within "1" seconds
   234  
   235      # Sleep as the deliver takes a bit to have the first block ready
   236      And I wait "1" seconds
   237  
   238  
   239      # Entry point for invoking on an existing channel
   240      When user "dev0Org0" creates a chaincode invocation spec "querySpec1" using spec "cc_spec" with input:
   241          | funcName  | arg1 |
   242          |   query   |  a   |
   243  
   244      # Under the covers, create a deployment spec, etc.
   245      And user "dev0Org0" using cert alias "dev0Org0App1" creates a proposal "queryProposal1" for channel "com.acme.blockchain.jdoe.Channel1" using chaincode spec "querySpec1"
   246  
   247      And user "dev0Org0" using cert alias "dev0Org0App1" sends proposal "queryProposal1" to endorsers with timeout of "30" seconds with proposal responses "queryProposal1Responses":
   248          | Endorser |
   249          | peer0    |
   250          | peer2    |
   251  
   252      Then user "dev0Org0" expects proposal responses "queryProposal1Responses" with status "200" from endorsers:
   253          | Endorser |
   254          | peer0    |
   255          | peer2    |
   256  
   257      And user "dev0Org0" expects proposal responses "queryProposal1Responses" each have the same value from endorsers:
   258          | Endorser |
   259          | peer0    |
   260          | peer2    |
   261  
   262  
   263      # Entry point for invoking on an existing channel
   264        When user "dev0Org0" creates a chaincode invocation spec "invocationSpec1" using spec "cc_spec" with input:
   265          | funcName   | arg1 | arg2 |  arg3  |
   266          |   invoke   |  a   |  b   |   10   |
   267  
   268      # Under the covers, create a deployment spec, etc.
   269        And user "dev0Org0" using cert alias "dev0Org0App1" creates a proposal "invokeProposal1" for channel "com.acme.blockchain.jdoe.Channel1" using chaincode spec "invocationSpec1"
   270  
   271        And user "dev0Org0" using cert alias "dev0Org0App1" sends proposal "invokeProposal1" to endorsers with timeout of "30" seconds with proposal responses "invokeProposal1Responses":
   272          | Endorser |
   273          | peer0    |
   274          | peer2    |
   275  
   276        Then user "dev0Org0" expects proposal responses "invokeProposal1Responses" with status "200" from endorsers:
   277          | Endorser |
   278          | peer0    |
   279          | peer2    |
   280  
   281        And user "dev0Org0" expects proposal responses "invokeProposal1Responses" each have the same value from endorsers:
   282          | Endorser |
   283          | peer0    |
   284          | peer2    |
   285  
   286        When the user "dev0Org0" creates transaction "invokeTx1" from proposal "invokeProposal1" and proposal responses "invokeProposal1Responses" for channel "com.acme.blockchain.jdoe.Channel1"
   287  
   288        And the user "dev0Org0" broadcasts transaction "invokeTx1" to orderer "<orderer2>" on channel "com.acme.blockchain.jdoe.Channel1"
   289  
   290      # Sleep as the deliver takes a bit to have the first block ready
   291        And I wait "2" seconds
   292  
   293        And user "dev0Org0" sends deliver a seek request on orderer "<orderer0>" with properties:
   294          | ChainId                               |   Start    |  End    |
   295          | com.acme.blockchain.jdoe.Channel1     |   2        |  2      |
   296  
   297        Then user "dev0Org0" should get a delivery "deliveredInvokeTx1Block" from "<orderer0>" of "1" blocks with "1" messages within "1" seconds
   298  
   299  
   300      # TODO: Once events are working, consider listen event listener as well.
   301  
   302      Examples: Orderer Options
   303        |          ComposeFile                                                                                                                       |  SystemUpWaitTime   | ConsensusType | BroadcastWaitTime | orderer0 | orderer1 | orderer2 |Orderer Specific Info|
   304        |   docker-compose-next-4.yml                                                                                                                |        0            |     solo      |      2            | orderer0 | orderer0 | orderer0 |                     |
   305  #      |   docker-compose-next-4.yml  ./environments/orderer-1-kafka-1/docker-compose.yml orderer-3-kafka-1.yml                                     |        5            |     kafka     |      5            | orderer0 | orderer1 | orderer2 |                     |
   306  #      |   docker-compose-next-4.yml  docker-compose-next-4-couchdb.yml                                                                             |        10            |     solo      |      2            | orderer0 | orderer0 | orderer0 |                     |
   307  #      |   docker-compose-next-4.yml  docker-compose-next-4-couchdb.yml  ./environments/orderer-1-kafka-1/docker-compose.yml orderer-3-kafka-1.yml  |        10            |     kafka     |      5            | orderer0 | orderer1 | orderer2 |                     |
   308  #      |   docker-compose-next-4.yml  ./environments/orderer-1-kafka-3/docker-compose.yml                                                           |          5          |     kafka     |      5            | orderer0 | orderer1 | orderer2 |                     |