Chaincode upgrades #322
Description
As far as I know, the peer never tries to stop chaincode after running it. There's nothing in the External Builders and Launchers documentation that covers stopping chaincode. After upgrading chaincode, new jobs will be started for the new version, however the old jobs will continue to run, which doesn't seem ideal. The k8s builder uses labels which can be used to find the jobs for a specific chaincode. For example:
export CCLABEL=$(peer lifecycle chaincode calculatepackageid go-contract.tgz | cut -d':' -f1)
export ENCODED_CCHASH=$(peer lifecycle chaincode calculatepackageid go-contract.tgz | cut -d':' -f2 | xxd -r -p | base32 | tr -d '=')
kubectl -n default describe jobs -l fabric-builder-k8s-cclabel=${CCLABEL},fabric-builder-k8s-cchash=${ENCODED_CCHASH}
These labels could be used to stop old chaincode jobs if required.
Is this a problem?
- Chaincode jobs should get tidied up when the peer restarts but do peers get restarted that often in production systems?
- Does/should the peer have some mechanism to stop old versions of chaincode?
- Should the k8s builder do anything more to help beyond labeling jobs? E.g. optionally adding a deadline to the chaincode jobs?