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 | |