[feature]peer lifecycle chaincode package support external chaincode

[davidkhala]

During learning and comparing external chaincode

bin/peer lifecycle chaincode package --label=diagnose --lang=external --path=...chaincode/golang/diagnose ccPackage.tar.gz I see the failure

Error: failed to normalize chaincode path: unknown chaincodeType: EXTERNAL

Is there any chance we can add external chaincode as allowed chaincodeType for this command?

[denyeart]

What do you think @mbwhite ?

[mbwhite]

Wanted to take this exact topic as part of closing out the CCas a service work..

@davidkhala would you be up for a collaborative effort?

[davidkhala]

ollaborative effort?

If not too complex, I would like to. while across the guide, reader like me get a little confused on the difference between external chaincode and ccaas. And back to this command opt, which wording should we use? external or ccaas?

[jkneubuh]

I was going to add a note / todo / work item in #3405 to track the addition of a new k8s external builder type... but this seems like a better placeholder for the effort.

Creating the "ccaas" chaincode package is still an ... exercise left to the reader .... it would be really nice if the peer cc package targets knew how to generate CC packages for the new builder types.

Both the "ccaas" and "k8s" builder types really just need a pointer to the label and Docker image to be run for the endpoint.

[jt-nti]

It would definitely be good if the peer lifecycle chaincode package command supported any builders provided out of the box.

@davidkhala

If not too complex, I would like to. while across the guide, reader like me get a little confused on the difference between external chaincode and ccaas. And back to this command opt, which wording should we use? external or ccaas?

Confusingly the original chaincode as an external service example in the documentation uses a type of external but that was a bit too vague so the relatively new built in chaincode as a server (CCaaS) builder uses a type of ccaas

One question is how will the new types be supported? At the moment you just give the command a path to package up, which should work if the correct file(s) is/are there. In the case of CCaaS, it needs to be a connection.json file with details of where the chaincode will be running, i.e. not a docker image name and tag because CCaaS doesn't care how the chaincode is started. This file could (should?) be validated in the package step. Similarly, the potential k8s builder requires an image.json file, and unlike the CCaaS connection.json this does contain a docker image name and tag.

The alternative is to add arguments for the settings required in the .json files. That's the approach used in the draft PR #3299 which has a basic shell script for creating CCaaS packages but I'm not sure how well that works when there are potentially a few package types.

[mbwhite]

Yes @jt-nti the peer cli could well struggle, and is out of it's depth already (eg. doesn't package typescript in the most efficient manner) I wonder if this is the chance to "re-light" the Fabric Admin CLI, or something much like it ( if I might suggest https://github.com/hyperledgendary/weftility as one source of ids... have added packaging updates to that push coming soon).

And/or provide the ability for the dev tools in the language of choice to produce the package from their pipelines. Generic github action or a gradle/maven plugin.

Sorry @davidkhala should have posted that sooner!

[davidkhala]

@mbwhite re-light is what I love ❤️ one year ago, Jay also discussed with me that if we can split out the roles peer binary is handling, "as a service" and "as a tool", these are contradicting especially some command options do not need any property value in core.yaml but still mandate an empty core.yaml over there to bypass san-check.

[mbwhite]

yes you're correct - requirement of core.yaml doesn't help @davidkhala

Thinking more about this - suggestion for a plan 'tactical/immediate' solution be to extend the peer package command to make it generic.

It takes as arguments (list from memory so might worth checking)

• location of the directory that becomes the code.tgz
• label
• type
• path of metadata for indexes
• path of collection config

And be very 'simple' it what it does - only basic are the files there... no language checks etc.

i.e. just a very simple package whatever it's told

[davidkhala]

yes you're correct - requirement of core.yaml doesn't help @davidkhala

Thinking more about this - suggestion for a plan 'tactical/immediate' solution be to extend the peer package command to make it generic.

It takes as arguments (list from memory so might worth checking)

• location of the directory that becomes the code.tgz
• label
• type
• path of metadata for indexes
• path of collection config

And be very 'simple' it what it does - only basic are the files there... no language checks etc.

i.e. just a very simple package whatever it's told

+1 Agree