As many of you know, Fabric v2.0 introduced external builders and launchers for chaincode: https://hyperledger-fabric.readthedocs.io/en/latest/cc_launcher.html.
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 ( https://hyperledger-fabric.readthedocs.io/en/latest/cc_service.html ) 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

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@...>
Cc:
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: https://hyperledger-fabric.readthedocs.io/en/latest/cc_launcher.html.
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 ( https://hyperledger-fabric.readthedocs.io/en/latest/cc_service.html ) 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
bbehlendorf@...
Twitter: @brianbehlendorf