hyperledger
adding external chaincode binaries to the base peer image WIP
Simplify the use of external chaincodes
Type of change
- New feature
- Improvement (improvement to code, performance, etc)
Might be a new feature or an improvement.
Description
Using external chaincode as a service needs to change the peer image providing three binaries (detect/build/release). To simplify the setup for use cases where docker (podman, kubernetes, openshift to name a few) is not available you are forced to use external chaincodes.
Additional details
As its basically my first PR for fabric, feedback regarding tools/guidelines would be appreciated. Maybe, the functionality could be moved into the existing tools in ccaasbuilder, but I wont risk a bug there.
Related issues
Release Note
The change wont impact existing installations
When ccaasbuilder was added, the thought was that it would be the one and only 'generic' builder included in the open source version of the peer. Other use case specific builders would have to be built into your own peer image, or perhaps shared in the fabric-samples repository.
That being said, I'd like to understand your use case and why you can't use the existing ccaasbuilder.
It looks like the externalbuilder code is a copy of the ccaasbuilder code?
totally agree, I just copied ccaasbuilder to make sure i dont interfere with existing functionality. If its ok for you, I would simply integrate the three cmds into existing ccaasbuilder commands. agree? My intention is to make external chaincode deployments simpler (as I'm using fabric in non-docker environments only). Personally, I can build my custom peer image as well and everything will work out for me, but my idea was to make it easier for others as well (e.g. kubernetes/openshift/podman users).
Ok, do you mean for discussion purposes you will update the externalbuilder code with your ideas? That would be fine for discussion. If your improvements are compatible enhancements with the existing ccaasbuilder, then you could just update ccaasbuilder. I'm still not sure the extent of changes you are proposing so I'll defer to your choice for the initial PR and discussion.
Also I'll mention that the name externalbuilder is not very clear, because that could imply a traditional external builder that actually builds chaincode, or a chaincode-as-a-service external 'builder' that points to an external service ('builder' in quotes because it doesn't actually build chaincode). I think you are talking about the latter.
so, I did find some time and would like ask for a small review @denyeart . I added remote as a type to detect (the ccaas binary), so we wont have additional commands. If its ok like its done for detect, I would proceed with build and release as well.