You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The contents of the chaincode package, i.e. the image.json file, must only contain details about the chaincode "inside" the package, and not any deployment configuration.
In the case of the k8s builder the chaincode is not actually inside the package, but in order not to break the Fabric chaincode lifecycle, the contents of the package must uniquely identify the chaincode that will eventually run.
An image digest does that, but a mutable tag does not.
Unfortunately that definitely causes problems for chaincode which hasn't been pushed to a repository, which potentially makes chaincode development more difficult. The chaincode as a server (CCaaS) builder is a better option for development environments, since it breaks the link between updates to the code and the chaincode lifecycle, and makes it easy to attach a debugger.
If there is feedback that there are significant usability problems with the CCaaS approach, then it may be worthwhile adding an unsafe development mode to the k8s builder to enable it to use unpublished chaincode images.
Using the built in Fabric CCAAS builder works well in a dev environment, allowing debugging and chaincode updates without going through the Fabric lifecycle every time. Pushing to a local registry seems to work reasonably well for samples and testing, so closing this as won't fix.
The contents of the chaincode package, i.e. the
image.json
file, must only contain details about the chaincode "inside" the package, and not any deployment configuration.In the case of the k8s builder the chaincode is not actually inside the package, but in order not to break the Fabric chaincode lifecycle, the contents of the package must uniquely identify the chaincode that will eventually run.
An image digest does that, but a mutable tag does not.
Unfortunately that definitely causes problems for chaincode which hasn't been pushed to a repository, which potentially makes chaincode development more difficult. The chaincode as a server (CCaaS) builder is a better option for development environments, since it breaks the link between updates to the code and the chaincode lifecycle, and makes it easy to attach a debugger.
If there is feedback that there are significant usability problems with the CCaaS approach, then it may be worthwhile adding an unsafe development mode to the k8s builder to enable it to use unpublished chaincode images.
See #27 for an initial investigation.
The text was updated successfully, but these errors were encountered: