Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add dev mode to allow builder to use unpublished cc images #29

Closed
jt-nti opened this issue May 19, 2022 · 1 comment
Closed

Add dev mode to allow builder to use unpublished cc images #29

jt-nti opened this issue May 19, 2022 · 1 comment
Labels
wontfix This will not be worked on

Comments

@jt-nti
Copy link
Member

jt-nti commented May 19, 2022

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.

@jt-nti
Copy link
Member Author

jt-nti commented Jan 30, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

1 participant