-
Notifications
You must be signed in to change notification settings - Fork 44
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
Chaincode Builder for Kubernetes RFC #56
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: James Taylor <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great for deployment in Kubernetes. I think making it a full Hyperledger (rather than labs) project makes the right statement of intent and support.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For better or worse, Kubernetes is the de facto mechanism for running cloud-native, container-based applications. The K8s-builder provides a production-grade approach to running smart contracts that is simple, extensible, and requires minimal operational expertise to quickly build and deploy chaincode on Fabric networks.
Networks constructed on Kubernetes using the k8s-builder have little to none of the associated "drama" that commonly occurs with root-enabled Docker daemons, external builders, Chaincode as a Service, or IDE plugins.
It just works. And I approve, wholeheartedly.
Thank you, @jt-nti for this incredible contribution to Hyperledger Fabric.
I agree the k8s builder is very compelling, the key question here is whether it should remain a lab or become an official subproject. One thing that distinguishes a lab from an official subproject is evidence of long-term maintenance. For example, is there some offering that intends to utilize the k8s builder that could provide resources to help maintain it long term? Also, the community is currently discussing the various k8s operator labs. I see the k8s builder as being part of that discussion and as such I think it could continue to evolve successfully as a lab along with the operators. A great outcome of those discussions would be a plan for maintaining an operator along with the k8s builder long term as subproject(s). In the short term, lab status seems to be a good place for such discussion, incubation, and evolution. But let's see if we can work together with the community on an overall plan for making kubernetes support more of a first class citizen as a subproject or set of subprojects that work together. |
110% behind this; |
Is it worth closing this dormant RFC while discussions continue on hyperledger/fabric#3984? |
Signed-off-by: James Taylor [email protected]