I am running Hyperledger Fabric 1.4.0
I have 1 org (Org1), 2 peers (peer0, peer1) and two orderers (ord0, ord1). The peers use couchdb as a storage backend.
I am able to successfully install my chaincode, then instantiate it.
Looking at peer0 logs, the docker image is built and the container started. peer0 also receives and acknowledges the REGISTER request sent by the chaincode binary within the container:
2019-06-24 10:15:57.003 UTC [dockercontroller] createContainer -> DEBU b563 created container {"imageID": "nid1-peer0-mynet-mychain-v1-613158e6e99c2c9e7d567e8b57fe2dfb56444f7fdcbc263dd1f61626a374843d", "containerID": "nid1-peer0-mynet-mychain-v1"}
2019-06-24 10:15:57.160 UTC [dockercontroller] Start -> DEBU b564 Started container nid1-peer0-mynet-mychain-v1
2019-06-24 10:15:57.160 UTC [container] unlockContainer -> DEBU b565 container lock deleted(mychain-v1)
2019-06-24 10:15:57.181 UTC [chaincode] handleMessage -> DEBU b566 [] Fabric side handling ChaincodeMessage of type: REGISTER in state created
2019-06-24 10:15:57.181 UTC [chaincode] HandleRegister -> DEBU b567 Received REGISTER in state created
2019-06-24 10:15:57.182 UTC [chaincode] Register -> DEBU b568 registered handler complete for chaincode mychain:v1
2019-06-24 10:15:57.182 UTC [chaincode] HandleRegister -> DEBU b569 Got REGISTER for chaincodeID = name:"mychain:v1" , sending back REGISTERED
2019-06-24 10:15:57.182 UTC [chaincode] HandleRegister -> DEBU b56a Changed state to established for name:"mychain:v1"
2019-06-24 10:15:57.182 UTC [chaincode] sendReady -> DEBU b56b sending READY for chaincode name:"mychain:v1"
2019-06-24 10:15:57.182 UTC [chaincode] sendReady -> DEBU b56c Changed to state ready for chaincode name:"mychain:v1"
2019-06-24 10:15:57.182 UTC [chaincode] Launch -> DEBU b56d launch complete
2019-06-24 10:15:57.182 UTC [chaincode] Execute -> DEBU b56e Entry
2019-06-24 10:15:57.182 UTC [chaincode] handleMessage -> DEBU b56f [1a98f442] Fabric side handling ChaincodeMessage of type: COMPLETED in state ready
Despite this, the chaincode is not registered in couchdb:
$ peer chaincode list --instantiated -C mychannel
2019-06-24 11:26:29.317 BST [main] InitCmd -> WARN 001 CORE_LOGGING_LEVEL is no longer supported, please use the FABRIC_LOGGING_SPEC environment variable
2019-06-24 11:26:29.332 BST [main] SetOrdererEnv -> WARN 002 CORE_LOGGING_LEVEL is no longer supported, please use the FABRIC_LOGGING_SPEC environment variable
Get instantiated chaincodes on channel mychannel:
peer0 logs immediately after submitting the list command:
2019-06-24 10:26:30.057 UTC [couchdb] ReadDocRange -> DEBU c02e [mychannel_lscc] HTTP/1.1 200 OK
Transfer-Encoding: chunked
Cache-Control: must-revalidate
Content-Type: application/json
Date: Mon, 24 Jun 2019 10:26:30 GMT
Server: CouchDB/2.1.1 (Erlang OTP/18)
X-Couch-Request-Id: 20d0beb9c3
X-Couchdb-Body-Time: 0
2a
{"total_rows":0,"offset":0,"rows":[
]}
0
If I try to invoke a method on the chaincode, I get this error:
Error: endorsement failure during invoke. response: status:500 message:"make sure the chaincode mychain has been successfully instantiated and try again: chaincode mychain not found"
which just confirms that the chaincode has not been registered within the network.
Update
I realised I had missed an important detail: the peer logs repeatedly report errors connecting to the orderer, e.g.:
2019-06-24 11:30:35.931 UTC [ConnProducer] NewConnection -> ERRO 100e6 Failed connecting to ord0.mynet.example.com , error: context deadline exceeded
which might be the reason why the "chaincode instantiated" message doesn't get propagated...
After much debugging, it turned out the issue was pretty simple: the peers could not communicate with the orderers.
In my particular case the addresses of the orderers were wrong in configtx.yaml. Fixing them resulted in the chaincode instantiation process tu fully succeed.
I tried instantiating well tested chaincode onto my fabric network but got issue summarized as "cannot register chaincode".
There is no trace of chaincode container. I have tested my chaincodes and they pass all the base tests so there is no issue with the code. No matter on whichever orgs peer I run this, instantiation keeps failing.
Can someone help?
Hyperledger fabric version controlling platform mentions a same bug filed but I don't see what solution they came up with (https://jira.hyperledger.org/browse/FAB-14638). They seem to say something about the node version mismatch.
cli logs :
peer chaincode instantiate -o orderer.flightcommand.com:7050 -C flightcommandchannel -l node -n TripCC -v v0 -c '{"Args":["init"]}' -P 'AND ("CapitalcityMSP.member")' 2019-05-08 05:40:55.146 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 001 Using default escc 2019-05-08 05:40:55.150 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 002 Using default vscc Error: could not assemble transaction, err proposal response was not successful, error code 500, msg chaincode registration failed: container exited with 0**
peer logs :
[flightcommandchannel][97cbe635] Exit chaincode: name:"lscc" (98834ms)
2019-05-08 05:42:33.897 UTC [endorser] SimulateProposal -> ERRO 18f [flightcommandchannel][97cbe635] failed to invoke chaincode name:"lscc" , error: container exited with 0
github.com/hyperledger/fabric/core/chaincode.(*RuntimeLauncher).Launch.func1 /opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/runtime_launcher.go:63 runtime.goexit /opt/go/src/runtime/asm_amd64.s:1333 chaincode registration failed
2019-05-08 05:42:33.898 UTC [comm.grpc.server] 1 -> INFO 190 unary call completed grpc.service=protos.Endorser grpc.method=ProcessProposal grpc.peer_address=192.168.96.12:38100 grpc.code=OK grpc.call_duration=1m38.836283s
I have finally found the issue. I missed out a ENV Variable to specify in the peer docker-compose.yaml.
"- CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE=network_1.0"
Where network_1.0 is the name of the docker network. Although the error messages was not so descriptive, I took some pain and rebuilt my prevoius project where chaincode deployment did work and compared it with my current project. Found only this piece missing and after adding it, to my surprise, everything worked.
Port 7052 is unlikely to be the problem here. This is the explanation (from core.yaml) about port 7052.
# The endpoint this peer uses to listen for inbound chaincode connections.
# If this is commented-out, the listen address is selected to be
# the peer's address (see below) with port 7052
# chaincodeListenAddress: 0.0.0.0:7052
In your debug output I see "chaincodeBuildlevel":"1.4.1-rc1"
I think you are using Fabric Images for 1.4.1-rc1.
I would suggest removing the Docker Images on your system and replacing with 1.4.1 and then using fabric-shim 1.4.1 too for consistency. This might clear the problem, but will certainly be a better place to continue investigations.
Updated following comments
With Docker Compose, if your group of containers are started on the same Network Bridge (on the same host machine/VM) they can resolve each others' addresses and connect on any port.
The mapping of Ports in the docker-compose.yaml file maps ports from the host computer into the container (not between containers).
Port 7053 used to be used for Events in older versions of Fabric, but it is not used in 1.4.1
The error you have now shown in the comment is a Name Resolution error so not to do with the ports. Perhaps your containers are not on the same Docker Bridge?
I modified the logging level of the peer and got to see something bizzare. Following are the chaincode logs in debug mode.
2019-05-08 11:21:52.980 UTC [endorser] callChaincode -> INFO 04f [flightcommandchannel][d01daf8c] Entry chaincode: name:"lscc"
2019-05-08 11:21:54.424 UTC [peer.chaincode.dev-peer0.onesky.flightcommand.com-AccountChaincode-v0] func2 -> INFO 050
2019-05-08 11:21:54.426 UTC [peer.chaincode.dev-peer0.onesky.flightcommand.com-AccountChaincode-v0] func2 -> INFO 051 > trip#1.0.0 start /usr/local/src
2019-05-08 11:21:54.427 UTC [peer.chaincode.dev-peer0.onesky.flightcommand.com-AccountChaincode-v0] func2 -> INFO 052 > **NODE_ENV=development node account.js "--peer.address" "peer0.onesky.flightcommand.com:7052"**
2019-05-08 11:21:54.428 UTC [peer.chaincode.dev-peer0.onesky.flightcommand.com-AccountChaincode-v0] func2 -> INFO 053
2019-05-08 11:21:55.124 UTC [peer.chaincode.dev-peer0.onesky.flightcommand.com-AccountChaincode-v0] func2 -> INFO 054 2019-05-08T11:21:55.118Z debug [lib/chaincode.js] debug: Starting chaincode using options {"_":[],"peer.address":"peer0.onesky.flightcommand.com:7052","chaincodeBuildlevel":"1.4.1-rc1","chaincodeLoggingLevel":"debug","chaincodeLoggingFormat":"%{color}%{time:2006-01-02 15:04:05.000 MST} [%{module}] %{shortfunc} -> %{level:.4s} %{id:03x}%{color:reset} %{message}","chaincodeIdName":"AccountChaincode:v0","chaincodeLoggingShim":"debug","peerTlsEnabled":"false","grpc.max_send_message_length":-1,"grpc.max_receive_message_length":-1,"grpc.keepalive_time_ms":110000,"grpc.http2.min_time_between_pings_ms":110000,"grpc.keepalive_timeout_ms":20000,"grpc.http2.max_pings_without_data":0,"grpc.keepalive_permit_without_calls":1,"module-path":"/usr/local/src","modulePath":"/usr/local/src","chaincode-id-name":"AccountChaincode:v0","timestamp":"2019-05-08T11:21:55.118Z"}
2019-05-08 11:21:55.128 UTC [peer.chaincode.dev-peer0.onesky.flightcommand.com-AccountChaincode-v0] func2 -> INFO 055 2019-05-08T11:21:55.127Z debug [lib/chaincode.js] debug: Peer URL {"0":"g","1":"r","2":"p","3":"c","4":":","5":"/","6":"/","7":"p","8":"e","9":"e","10":"r","11":"0","12":".","13":"o","14":"n","15":"e","16":"s","17":"k","18":"y","19":".","20":"f","21":"l","22":"i","23":"g","24":"h","25":"t","26":"c","27":"o","28":"m","29":"m","30":"a","31":"n","32":"d","33":".","34":"c","35":"o","36":"m","37":":","38":"7","39":"0","40":"5","41":"2","timestamp":"2019-05-08T11:21:55.127Z"}
2019-05-08 11:21:55.135 UTC [peer.chaincode.dev-peer0.onesky.flightcommand.com-AccountChaincode-v0] func2 -> INFO 056 2019-05-08T11:21:55.135Z info [lib/chaincode.js] info: Registering with peer peer0.onesky.flightcommand.com:7052 as chaincode "AccountChaincode:v0" {"timestamp":"2019-05-08T11:21:55.135Z"}
2019-05-08 11:21:55.147 UTC [peer.chaincode.dev-peer0.onesky.flightcommand.com-AccountChaincode-v0] func2 -> INFO 057 2019-05-08T11:21:55.146Z debug [lib/handler.js] debug: Sending chat message: {"type":1,"payload":{"type":"Buffer","data":[18,19,65,99,99,111,117,110,116,67,104,97,105,110,99,111,100,101,58,118,48]}} {"timestamp":"2019-05-08T11:21:55.146Z"}
2019-05-08 11:21:55.440 UTC [peer.chaincode.dev-peer0.onesky.flightcommand.com-AccountChaincode-v0] func2 -> INFO 058 2019-05-08T11:21:55.437Z error [lib/handler.js] error: Chat stream with peer - on error: "Error: 14 UNAVAILABLE: Name resolution failure\n at Object.exports.createStatusError (/usr/local/src/node_modules/grpc/src/common.js:91:15)\n at ClientDuplexStream._emitStatusIfDone (/usr/local/src/node_modules/grpc/src/client.js:233:26)\n at ClientDuplexStream._receiveStatus (/usr/local/src/node_modules/grpc/src/client.js:211:8)\n at Object.onReceiveStatus (/usr/local/src/node_modules/grpc/src/client_interceptors.js:1306:15)\n at InterceptingListener._callNext (/usr/local/src/node_modules/grpc/src/client_interceptors.js:568:42)\n at InterceptingListener.onReceiveStatus (/usr/local/src/node_modules/grpc/src/client_interceptors.js:618:8)\n at /usr/local/src/node_modules/grpc/src/client_interceptors.js:1123:18" {"timestamp":"2019-05-08T11:21:55.437Z"}
2019-05-08 11:21:55.617 UTC [dockercontroller] func2 -> INFO 059 Container dev-peer0.onesky.flightcommand.com-AccountChaincode-v0 has closed its IO channel
2019-05-08 11:21:56.091 UTC [endorser] callChaincode -> INFO 05a [flightcommandchannel][d01daf8c] Exit chaincode: name:"lscc" (3111ms)
2019-05-08 11:21:56.091 UTC [endorser] SimulateProposal -> ERRO 05b [flightcommandchannel][d01daf8c] failed to invoke chaincode name:"lscc" , error: container exited with 0
github.com/hyperledger/fabric/core/chaincode.(*RuntimeLauncher).Launch.func1
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/runtime_launcher.go:63
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:1333
chaincode registration failed
2019-05-08 11:21:56.091 UTC [comm.grpc.server] 1 -> INFO 05c unary call completed grpc.service=protos.Endorser grpc.method=ProcessProposal grpc.peer_address=172.25.0.4:59932 grpc.code=OK grpc.call_duration=3.1157286s
So here lies the problem. My peer listens on port 7051, not 7052. Ideally the command should look like "NODE_ENV=development node account.js "--peer.address" "peer0.onesky.flightcommand.com:7051"". I have no idea from where it is getting 7052.
P.S.
I added following to get a better overview of the issue in the chaincode instantiation.
FABRIC_LOGGING_SPEC=info
CORE_CHAINCODE_LOGGING_SHIM=debug
CORE_CHAINCODE_LOGGING_LEVEL=debug
core.yaml says
# The endpoint this peer uses to listen for inbound chaincode connections.
# If this is commented-out, the listen address is selected to be
# the peer's address (see below) with port 7052
# chaincodeListenAddress: 0.0.0.0:7052
# The endpoint the chaincode for this peer uses to connect to the peer.
# If this is not specified, the chaincodeListenAddress address is selected.
# And if chaincodeListenAddress is not specified, address is selected from
# peer listenAddress.
# chaincodeAddress: 0.0.0.0:7052
So I concluded since both are commented, 7051 is used as the address to listen to chaincode.
I faced exactly the same problem whenever I tried to instantiate the chaincode, I got this error
peer logs:
2019-05-09 04:05:38.285 EDT [endorser] SimulateProposal -> ERRO 15c [mychannel][03349c15] failed to invoke chaincode name:"lscc" , error: container exited with 1
github.com/hyperledger/fabric/core/chaincode.(*RuntimeLauncher).Launch.func1
/home/alex/go/src/github.com/hyperledger/fabric/core/chaincode/runtime_launcher.go:63
runtime.goexit
/usr/local/go/src/runtime/asm_amd64.s:1337
chaincode registration failed
I was able to fix it by changing build.gradle file, make sure in your build.gradle you have set Main-Class in manifest attributes to your main java file.
shadowJar {
baseName = 'chaincode'
version = null
classifier = null
manifest {
attributes 'Main-Class': 'org.hyperledger.fabric.chaincode.XXX'
}
}
Where XXX is the XXX.java file where your main() function is defined
Not sure how can this be done in node. But I hope this will give you the idea.
i faced the same issue not find any solution yet.
2021-03-25 04:53:55.840 UTC [endorser] SimulateProposal -> ERRO 046 failed to invoke chaincode bankcc, error: container exited with 0
github.com/hyperledger/fabric/core/chaincode.(*RuntimeLauncher).Launch.func1
/go/src/github.com/hyperledger/fabric/core/chaincode/runtime_launcher.go:118
and this my chaincode container logs
Error starting Marbles02 chaincode: ccid must be specified
but i specified the ccid here
server := &shim.ChaincodeServer{
//CCID: ccid,
CCID: os.Getenv("CHAINCODE_CCID"),
Address: os.Getenv("CHAINCODE_ADDRESS"),
CC: chaincode,
TLSProps: shim.TLSProperties{
Disabled: true,
},
I had the same problem,and I have sloved it by change peer env,and I think this problem was caused by CORE_PEER_ADDRESSAUTODETECT,actual,I dont know why .
I set CORE_PEER_ADDRESSAUTODETECT=true ,commented CORE_PEER_CHAINCODEADDRESS and CORE_PEER_CHAINCODELISTENADDRESS,It is work.
my peer env like this :
CORE_PEER_ADDRESSAUTODETECT=true
#CORE_PEER_CHAINCODEADDRESS=peer0.org1.example.com:30012
#CORE_PEER_CHAINCODELISTENADDRESS=0.0.0.0:30012
The instantiation command completes successfully, but when analyzing peer logs, you may notice this:
2019-04-17 17:25:52.581 UTC [gossip.state] commitBlock -> DEBU 48c [canal-contrato] Committed block [1] with 1 transaction(s)
2019-04-17 17:25:52.581 UTC [common.deliver] deliverBlocks -> DEBU 48d [channel: canal-contrato] Delivering block for (0xc00023f9c0) for 192.168.16.1:48230
2019-04-17 17:25:52.581 UTC [fsblkstorage] waitForBlock -> DEBU 48e Going to wait for newer blocks. maxAvailaBlockNumber=[1], waitForBlockNum=[2]
2019-04-17 17:25:52.586 UTC [common.deliver] deliverBlocks -> DEBU 48f Context canceled, aborting wait for next block
2019-04-17 17:25:52.586 UTC [common.deliverevents] func1 -> DEBU 490 Closing Deliver stream
2019-04-17 17:25:52.586 UTC [comm.grpc.server] 1 -> INFO 491 streaming call completed {"grpc.start_time": "2019-04-17T17:25:50.441Z", "grpc.service": "protos.Deliver", "grpc.method": "DeliverFiltered", "grpc.peer_address": "192.168.16.1:48230", "error": "context finished before block retrieved: context canceled", "grpc.code": "Unknown", "grpc.call_duration": "2.144399922s"}
Can anyone orient me what I'm possibly doing wrong and what are the consequences of this error?
Notes:
The orderer logs don't present any type of error
All containers are running correctly
I'm using node version 8.9.0 (with npm 5.5.1)
I have 1 organization with 1 peer, 1 CA and 1 ordered (just to test)
I'm using hyperlegder fabric version 1.4
This is not an error. You are using an SDK that connects to the peer and waits for the instantiate to finish. The block is received by the peer, and when it does - the SDK closes the gRPC stream because it doesn't need it anymore, and the peer logs this to notify you why it closed the stream from the server side.
I am trying to enable peer/orderer logging in the Balance Transfer sample of Hyperledger Fabric, so I can understand the step-by-step consensus and transaction process of my Hyperledger Fabric project.
---------
If we start the blockchain network of chaincode-docker-devmode, and go to the Terminal 1 where this command below is executed
docker-compose -f docker-compose-simple.yaml up
We can easily see all the peer/orderers/cli logs in the terminal, for example like this:
peer | 2018-07-26 08:58:07.426 UTC [chaincode] Execute -> DEBU 73d Entry
peer | 2018-07-26 08:58:07.426 UTC [chaincode] Execute -> DEBU 73e chaincode canonical name: escc:1.1.0
orderer | 2018-07-26 08:58:07.434 UTC [policies] Evaluate -> DEBU 3c4 Signature set satisfies policy /Channel/Orderer/SampleOrg/Writers
orderer | 2018-07-26 08:58:07.434 UTC [policies] Evaluate -> DEBU 3c5 == Done Evaluating *cauthdsl.policy Policy /Channel/Orderer/SampleOrg/Writers
orderer | 2018-07-26 08:58:07.434 UTC [policies] Evaluate -> DEBU 3c6 Signature set satisfies policy /Channel/Orderer/Writers
peer | 2018-07-26 08:58:07.426 UTC [chaincode] sendExecuteMessage -> DEBU 73f [82a18317]Inside sendExecuteMessage. Message TRANSACTION
peer | 2018-07-26 08:58:07.426 UTC [chaincode] setChaincodeProposal -> DEBU 740 Setting chaincode proposal context...
orderer | 2018-07-26 08:58:07.435 UTC [policies] Evaluate -> DEBU 3c7 == Done Evaluating *policies.implicitMetaPolicy Policy /Channel/Orderer/Writers
orderer | 2018-07-26 08:58:07.435 UTC [policies] Evaluate -> DEBU 3c8 Signature set satisfies policy /Channel/Writers
orderer | 2018-07-26 08:58:07.435 UTC [policies] Evaluate -> DEBU 3c9 == Done Evaluating *policies.implicitMetaPolicy Policy /Channel/Writers
orderer | 2018-07-26 08:58:07.436 UTC [orderer/common/blockcutter] Ordered -> DEBU 3ca Enqueuing message into batch
orderer | 2018-07-26 08:58:07.436 UTC [orderer/common/broadcast] Handle -> DEBU 3cb [channel: myc] Broadcast has successfully enqueued message of type ENDORSER_TRANSACTION from 172.23.0.5:57804
peer | 2018-07-26 08:58:07.426 UTC [chaincode] setChaincodeProposal -> DEBU 741 Proposal different from nil. Creating chaincode proposal context...
In my case, I want to replicate that condition into the Balance Transfer sample. So when I run ./runApp.sh, it will show all the logs.
How can I do that? What environment should I put in Balance Transfer's docker-compose.yaml file?
Thanks!
In balance transfer go to directory artifacts and type this command.
docker-compose -f docker-compose.yaml logs -f for live logging.[1][2]
docker-compose -f docker-compose.yaml logs` for upto the point logs with no live logging.
NOTE : When you run the script in balance-transfer, docker starts the docker containers in detached mode : Run containers in the background,print new container names. That's the reason logs are not shown as soon as containers are orchestrated.[3][4]
References :
[1] : Docker - How do I view real time logging of Docker containers? (https://success.docker.com/article/view-realtime-container-logging)
[2] : docker container logs | Docker Documentation (https://docs.docker.com/engine/reference/commandline/container_logs/)
[3] : docker run | Docker Documentation (https://docs.docker.com/engine/reference/commandline/run/)
[4] : docker-compose up | Docker Documentation (https://docs.docker.com/compose/reference/up/)
There are multiple peer nodes, a single orderer and a single CA authority for production and want to deploy the chaincode. I have the compiled chaincode and the go file in a directory called chaincode-app/
The peer node has a docker instance running with the name peer0-vm. I want to deploy my chaincode using this peer. When I run
docker exec peer0-vm peer chaincode install -n mycc -v 1.0 -p chaincode-app/
I receive the following error:
2018-01-03 05:35:30.577 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 001 Using default escc
2018-01-03 05:35:30.578 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 002 Using default vscc
Error: Error getting chaincode code chaincode: <go, [env]>: failed with error: "exec: not started"
The peer logs are as follows:
2018-01-02 11:00:29.826 UTC [gossip/gossip] NewGossipService -> WARN 014 External endpoint is empty, peer will not be accessible outside of its organization
2018-01-02 11:00:29.829 UTC [gossip/gossip] start -> INFO 015 Gossip instance 0.0.0.0:7051 started
2018-01-02 11:00:29.830 UTC [cscc] Init -> INFO 016 Init CSCC
2018-01-02 11:00:29.830 UTC [sccapi] deploySysCC -> INFO 017 system chaincode cscc/(github.com/hyperledger/fabric/core/scc/cscc) deployed
2018-01-02 11:00:29.830 UTC [sccapi] deploySysCC -> INFO 018 system chaincode lscc/(github.com/hyperledger/fabric/core/scc/lscc) deployed
2018-01-02 11:00:29.831 UTC [escc] Init -> INFO 019 Successfully initialized ESCC
2018-01-02 11:00:29.831 UTC [sccapi] deploySysCC -> INFO 01a system chaincode escc/(github.com/hyperledger/fabric/core/scc/escc) deployed
2018-01-02 11:00:29.831 UTC [sccapi] deploySysCC -> INFO 01b system chaincode vscc/(github.com/hyperledger/fabric/core/scc/vscc) deployed
2018-01-02 11:00:29.831 UTC [qscc] Init -> INFO 01c Init QSCC
2018-01-02 11:00:29.831 UTC [sccapi] deploySysCC -> INFO 01d system chaincode qscc/(github.com/hyperledger/fabric/core/chaincode/qscc) deployed
2018-01-02 11:00:29.832 UTC [nodeCmd] initSysCCs -> INFO 01e Deployed system chaincodess
2018-01-02 11:00:29.832 UTC [nodeCmd] serve -> INFO 01f Starting peer with ID=[name:"fabsmbqxc-peer0.org1.example.com" ], network ID=[dev], address=[0.0.0.0:7051]
2018-01-02 11:00:29.832 UTC [nodeCmd] serve -> INFO 020 Started peer with ID=[name:"fabsmbqxc-peer0.org1.example.com" ], network ID=[dev], address=[0.0.0.0:7051]
2018-01-02 14:06:22.467 UTC [chaincode] notifyDuringStartup -> WARN 021 trying to manually run chaincode when not in devmode ?
2018-01-02 14:06:22.467 UTC [chaincode] HandleMessage -> ERRO 022 []Failed to trigger FSM event REGISTER: transition canceled with error: peer will not accepting external chaincode connection name:"chaincode-app:1.0" (except in dev mode)
2018-01-02 14:06:22.467 UTC [chaincode] processStream -> ERRO 023 []Error handling message, ending stream: transition canceled with error: peer will not accepting external chaincode connection name:"chaincode-app:1.0" (except in dev mode)
On a quick read, I understood that the chaincode cannot be executed by the user and should be instead done by the peer. Can someone point out how I could deploy this chaincode?
I've tried to follow the lifecycle of package -> install -> instantiate -> upgrade and tried to package the chaincode before signing and installing using the command but failed.
docker exec peer0-vm peer chaincode package -n mycc -v 1.0 -p chaincode-app -s -S ccpack.out
Could someone point out where I am going wrong and a possible solution?
The peer node has a docker instance running with the name peer0-vm. I want to deploy my chaincode using this peer.
Running CLI install from the peer container won't work.
If you are using docker to execute CLI you should use containers built from hyperledger/fabric-tools. The e2e_cli samples under fabric/examples/e2e_cli is a good reference for all this. In particular do take a look at how the CLI is constructed in docker-compose-cli.yaml please.
There may be other issues but this would be the first one to fix to make sure install works.