Open muralisrini opened 8 years ago
We need to separate instance (not there today) and deploy (which is a one time operation). Semantics of deploy is "one time" (it always returns the same "transaction id" as stored on the ledger).
Also when chaincode instance is implemented, each instance would need to be identified uniquely as well - but that's a different discussion.
@muralisrini I tried and succeeded in deploying a chaincode twice:
vagrant@vagrant-ubuntu-trusty-64:/opt/gopath/src/github.com/openblockchain/obc-peer$ OPENCHAIN_PEER_ADDRESS=10.0.2.15:30303 ./obc-peer chaincode deploy -p github.com/openblockchain/obc-peer/openchain/example/chaincode/chaincode_example02 -c '{"Function":"init", "Args":["a", "1", "b", "1"]}' --logging-level=info
15:01:51.623 [main] chaincodeDeploy -> INFO 001 Deploy result: type:GOLANG chaincodeID:<path:"github.com/openblockchain/obc-peer/openchain/example/chaincode/chaincode_example02" name:"bddbf5b909a9eacf97bfeaba9991b04a36dd5e437167f6bda6fbc0add4641d81b7eba987236acdf1a73d6742af1a0ada2b24b86123141708281504cd241fdbb8" > ctorMsg:<function:"init" args:"a" args:"1" args:"b" args:"1" >
vagrant@vagrant-ubuntu-trusty-64:/opt/gopath/src/github.com/openblockchain/obc-peer$ OPENCHAIN_PEER_ADDRESS=10.0.2.15:30303 ./obc-peer chaincode deploy -p github.com/openblockchain/obc-peer/openchain/example/chaincode/chaincode_example02 -c '{"Function":"init", "Args":["a", "1", "b", "1"]}' --logging-level=info
15:02:41.237 [main] chaincodeDeploy -> INFO 001 Deploy result: type:GOLANG chaincodeID:<path:"github.com/openblockchain/obc-peer/openchain/example/chaincode/chaincode_example02" name:"bddbf5b909a9eacf97bfeaba9991b04a36dd5e437167f6bda6fbc0add4641d81b7eba987236acdf1a73d6742af1a0ada2b24b86123141708281504cd241fdbb8" > ctorMsg:<function:"init" args:"a" args:"1" args:"b" args:"1" >
Change to sev3 since the user can control this
@muralisrini I'm confused... is /deploy intended to be idempotent? If so, then the title and suggested fix) is incorrect. If indeed the expected behavior is as you say above: "Semantics of deploy is "one time" (it always returns the same "transaction id" as stored on the ledger)." then we don't want it to return an error, we want it to return the same transaction id.
That aside, bug reports should have information as to how to reproduce the error so that someone taking on the task of fixing has something with which to work. Binh's example code https://github.com/hyperledger/fabric/issues/581#issuecomment-182411613 should suffice for this one (although it needs to be transposed from openblockchain to hyperledger).
@christo4ferris : Agree I should have added details....
This issue is about how we should handle redeploys of an existing chaincode. The details of deploy are (1) create the image (2) launch the chaincode and (3) call "init". "init" is a one time operation signifying creation of chaincode, so by extension deploy should also be an one time operation. Currently we don't treat redeploy as an error.
There are two ways to handle error from redeploy
Option 2 is is consistent with how "invoke" transaction's outcomes are handled. My preference would be for option 2.
Related Currently there is no proper "instance" support.When we do support it, users will be able to create instances of chaincode. That will also clarify the difference between current deploy and instantiate. Extensive discussion on instances in #373.
@muralisrini where do we stand with this?
Why? isn't it conceivable that you want to run two separate chaincode instances that are created the same way?