Re: Chaincode as an external service

Brian Behlendorf <bbehlendorf@...>

I just wanted to say, this thread is such a stellar example of Doing Open Source Right - a clear explanation of an issue & decision needing to be made, followed by a call for volunteers, followed by those who were interested in this committing to work together to complete the work. Kudos to everyone!


On 6/22/20 6:57 PM, Xiang Dong Hu wrote:
Hello David,
We are also trying to leverage the chaincode as an external service feature since it brings new possibility of deployment model for chaincode...
I'm also interested in contributing to this feature including integration test.
----- Original message -----
From: "David Enyeart" <enyeart@...>
Sent by: fabric@...
To: fabric <fabric@...>
Subject: [EXTERNAL] [Hyperledger Fabric] Chaincode as an external service
Date: Mon, Jun 22, 2020 5:28 PM

As many of you know, Fabric v2.0 introduced external builders and launchers for chaincode:
This feature is seeing adoption from people that don't want to rely on the elevated peer privileges required to build and launch chaincode using the Docker daemon. It is well tested in Fabric CI and maintained as a first class Fabric feature.

A related feature called Chaincode as an external service ( ) was also introduced and allowed for running chaincode as an external service (perhaps as a clustered service), where the peer simply connects to an existing chaincode service rather than building and launching it. This feature has not seen as much traction - the integration test was not completed in the automated CI test suite and the original contributors have largely moved on to other work outside Fabric and are not using it. This begs the question of what to do with the Chaincode as an external service feature going forward. Let me ask a few questions to the community to start a dialog on the topic...

- Has anybody started to adopt the Chaincode as an external service deployment model?
- Would anybody be interested in helping to complete the integration test and maintain the feature going forward?

In general, features that are not adopted or maintained may get deprecated and eventually removed from the project. Obviously this is not a desired outcome for a new feature, therefore please respond if you are interested in the feature and able to help.

Finally, it is worth highlighting the general operating policy that new features must include unit and integration test automated CI coverage before becoming available in a release. This feature made it into v2.0 since the integration tests were in progress and it looked like they would be completed prior to the v2.0 release date. That didn't happen and still hasn't happened however. In the future I think we as maintainers need to be more rigorous about enforcing the test coverage policies, and removing features before a release if needed, to avoid having such features in limbo.

Dave Enyeart


Brian Behlendorf
Executive Director, Hyperledger
Twitter: @brianbehlendorf

Join { to automatically receive all group messages.