[FAB-14083] Chaincode as an external service documentation #399
Conversation
pamandrejko
requested review from
ale-linux,
binhn,
C0rWin,
christo4ferris,
denyeart,
guoger,
jyellick,
kchristidis,
manish-sethi,
mastersingh24,
muralisrini,
sykesm and
yacovm
as code owners
pamandrejko
force-pushed
the
FAB-14083
branch
4 times, most recently
from
bc9beae
to
09c867d
Compare
Signed-off-by: pama-ibm <pama@ibm.com> Update docs/source/cc_service.md Co-Authored-By: denyeart <enyeart@us.ibm.com> Update docs/source/cc_service.md Co-Authored-By: denyeart <enyeart@us.ibm.com> [FAB-14083] Chaincode as a service documentation Co-Authored-By: denyeart <enyeart@us.ibm.com> Signed-off-by: pama-ibm <pama@ibm.com> [FAB-14083] External chaincode as a service
pamandrejko
force-pushed
the
FAB-14083
branch
from
09c867d
to
1432b66
Compare
denyeart
dismissed stale reviews from sykesm and jyellick
comments addressed.
|
comments addressed. lgtm. |
|
|
||
| ### code.tar.gz archive requirements | ||
|
|
||
| The `code.tar.gz` archive must include connection information for the chaincode endpoint. This information is packaged into `connection.json` in the `/bin/release` step (see below). In this example we package `connection.json` directly in `code.tar.gz` so the `release` step can just copy it over. |
There was a problem hiding this comment.
This still isn't correct. We are prescribing a sample implementation instead of documenting the function in fabric.
| "key_path": "path/rooted/in/release/directory/key.pem", | ||
| "cert_path": "path/rooted/in/release/directory/cert.pem", | ||
| "root_cert_path": "path/rooted/in/release/directory/rootcert.pem" |
There was a problem hiding this comment.
There's a JIRA opened to change these to be values within the document instead of spreading them around the tree. That changes the key and the semantics and keep the definitions consistent between chaincode clients (what we have today) and chaincode servers (what this is talking about).
I really don't think it will make beta so this is mostly informational...
| {"path":"","type":"external","label":"mycc"} | ||
| ``` | ||
|
|
||
| ## Configuring a peer to process external chaincode |
There was a problem hiding this comment.
I really think most of this unnecessarily overlaps with what we have in the other doc.
In my earlier comment I suggested the areas to focus on here; I'll go further and say that I think the connection.json should be documented or linked within the /bin/release portion of external builders as that's really the only intersection between the two.
| if [ "$#" -ne 2 ]; then | ||
| >&2 echo "Expected 2 directories got $#" | ||
| exit 2 | ||
| fi |
There was a problem hiding this comment.
We're needlessly complicating examples by having these assertions. It looks like we're just copying the contents of tests.
|
@muralisrini Will address the remaining comments in subsequent PR. |
Signed-off-by: pama-ibm pama@ibm.com
Adding a new topic to the documentation for configuring chaincode as an external service.
Description
Content includes an entry in the Operations Guide toc and the new topic which describes the process for configuring Chaincode as an external service.
Source material came from Murali here: https://docs.google.com/document/d/1WhJmbHt7JXNCStXWyM7eaTxUaA9PAlfHwVPI5RUnOAQ/edit?usp=sharing
Related issues
FAB-16906 External Builder and Launcher #386
Release Note
@denyeart We need to update the release notes and what's new if you have not already.