search

Substra / hlf-k8s

Initializes an Hyperledger Fabric network (orchestrator distributed mode)
https://docs.substra.org
Apache License 2.0
31 stars 20 forks source link

Add chaincode upgrade procedure (test environment only) #104

Closed AurelienGasser closed 3 years ago

AurelienGasser commented 3 years ago

A first step towards https://github.com/SubstraFoundation/hlf-k8s/issues/50

Kelvin-M commented 3 years ago

Nice work, but it's not a Hyperledger Fabric upgrade, it's a helm/kubernetes one.

Our operator does not handle chaincode upgrade. Clément shares a good link : https://hyperledger-fabric.readthedocs.io/en/release-2.2/chaincode_lifecycle.html#upgrade-a-chaincode To upgrade a chaincode you need to build a new chaincode definition on sequence incremented If you look inside the app channel operator, multiple things happen

 fabric-tools [DEBUG] Fetching the channel (mychannel) configuration block
 fabric-tools [DEBUG] Check if MyOrg1 is in the application channel
 fabric-tools [DEBUG] MyOrg1 is already in the application channel
 fabric-tools [DEBUG] Fetching the channel (mychannel) configuration block
 fabric-tools [DEBUG] Check if MyOrg2 is in the application channel
 fabric-tools [DEBUG] MyOrg2 is already in the application channel
 fabric-tools sh: -: not found
 fabric-tools [DEBUG] Wait chaincode ready mycc 2.0 on channel mychannel
 fabric-tools [DEBUG] Commit chaincode mycc 2.0 on channel mychannel
 fabric-tools cat: can't open 'endorsement.config': No such file or directory
 fabric-tools go package net: GODEBUG setting forcing use of Go's resolver
 fabric-tools Error: proposal failed with status: 500 - failed to invoke backing implementation of 'CommitChaincodeDefinition': requested sequence is 1, but new definition must be sequence 2
 fabric-tools go package net: GODEBUG setting forcing use of Go's resolver

We don't rebuild ENDORSEMENT variable correctly, that's why we need to use discovery instead or move this part to be done systematically. Handle --sequence value, here, hardcoded to 1 Do a real chaincode upgrade, not replace the image of the container. The chaincode_ccid secret does not change if we follow your procedure, and the channel is not aware of any upgrade.

Here, you procedure is equivalent to : [kubernetes] change chaincode deployment container image from 0.1.1 to 0.1.2 [hlf] install a new chaincode package, but don't create new ccid secret as it already exists (base on name only, not name and version)

AurelienGasser commented 3 years ago

Thanks fro the feedback @Kelvin-M.

I'm going to close this PR for now as it's not quite valuable in its current state.

However, there are valuable pointers in this PR. We can refer to it in the future, when we will invest time writing a full upgrade procedure. We can easily find it by looking for "chaincode upgrade" in closed PRs.