Kube test network : Chaincode as an external service only in one organization

[charalarg]

Hello everyone,

Is there any reason that the chaincode is installed, launched and activated only in the org1 as we can see on this file?

Would it be the same if these steps ran on org0 or org2, or maybe on both org1 and org2?

[denyeart]

@mbwhite @jkneubuh ?

[mbwhite]

No particular reason that I can recall; it would be reasonable to also deploy this on org1 and org2... org0 is the Orderer's organization so not applicable here.

Only practical considerations of keeping the load down, and the number of running containers, but no reason really. PRs are more than welcome if anybody would like to make updates :-)

[charalarg]

Thank you for your quick response, i really appreciate that!

[satota2]

PRs are more than welcome if anybody would like to make updates :-)

Hello @mbwhite @jkneubuh, I am interested in creating this PR because I think the update would be more appropriate as a reference guide for production-style networks. May I take on the issue? If it's OK, let me discuss the specifications that should be implemented with you.

• Q. Would it be sufficient to add deployment to org2 as well as org1 by hardcoding? Or should deployment to org2 be optional?
  • I am worried about conflicts with other activities.
• Q. I think that it would be more practical to change Endorsement and LifecycleEndorsement from OR('Org1MSP.peer','Org2MSP.peer') to MAJORITY Endorsement. How about this?
  • cf. https://github.com/hyperledger/fabric-samples/blob/main/test-network-k8s/config/org0/configtx.yaml

[jkneubuh]

Hi @satota2

This would be a nice addition. I went through some PRs last week related to the ERC / Token samples, both of which require chaincocde to be installed for multiple orgs in the network. (I didn't commit / merge / PR the changes, but this would have saved some time had it already been in the repo.)

Also - please be aware that PR #684 is in the wings and has made substantial changes to the chaincode.sh script. This branch (jkneubuh/feature/java-ccaas-slim) will provide a much better basis for refactoring the installation to work with multiple organizations. If possible, try to get the "hardcoding" of org1 / org2 down to a single spot in the code, passing in an org name as a parameter to a high-level routine in the script. That way if we want to change the default behavior, it should be a straightforward edit.

Regarding the default behavior... I think it would be preferable to illustrate the current "best practice" for deploying chaincode by creating one instance of the chaincode for each org/peer in the network. This seems a bit excessive... but there have been some discussions and questions related to load balancing chaincode (see fabric Discussion #3350) and it might be best to highlight the target deployment, even if it consumes a bit more resources on the KIND cluster.

I'll defer to @mbwhite and @denyeart on pros/cons of changing the CC endorsement policy. In general, I'd recommend setting up the network with "OR" by default, and then using this as a mechanism in the documentation to show how/where end-users can alter the policy if the application dictates (e.g. in a token transfer / monetary value exchange.)

[satota2]

Hi @jkneubuh, I appreciate your comments and for agreeing to add this.

Also - please be aware that PR #684 is ...

Thank you for the information about PR #684. I understand that it is better to use this patch as the base. So, I will wait for the merge. I will also try to avoid hard-coded parts as much as possible when implementing this.

Regarding the default behavior... I think it would be preferable to illustrate the current "best practice" ...

I read your comments as that, the best practice/current recommendation is to deploy a chaincode instance 1:1 with the peer, but it are still under discussion, including matters related to Load Balancing Chaincode as a Service. How about implementing it 1:1 first, and then later respond when best practices are updated?

I'll defer to @mbwhite and @denyeart on pros/cons of changing the CC endorsement policy.

OK! I will share my detail opinion below. I hope this helps in your consideration.

• (a) Which is better to use implicit rules (e.g., "ANY Endorsement") or explicit rules (e.g., "OR('Org1MSP.peer','Org2MSP.peer')")
  • As you know, the former does not need to be updated when peer organizations are added. The procedure may be simple when introducing the example to add org3 like the original test-network in the future.
  • The latter might be easy to understand what is required to satisfy the endorsement policy.
• (b) Which is better single org (OR) endorsement or majority (AND) endorsement
  • I thought it would be better to at least set LifecycleEndorsement to MAJORITY (or equivalent "Org1 AND Org2" condition) to make the chaincode governance model easier to understand.
  • As for Endorsement, I agree that it depends on the sample application (In this case, is the target asset-transfer?).

[jkneubuh]

Hi @satota2 / Sato さん - PR #724 has landed and replaces the (closed / invalid) PR #684. Please proceed with the updates when you are ready - the updated code has a much improved flow for working with the organizations as parameters in the chaincode functions.

Deploying 1:1 chaincode to peer is a good start. Let's start with this approach, and re-visit if we have resource constraints.

Load-balancing chaincode is a longer thread, and we should probably start first by extending the network with some monitoring, logging, and performance hooks. E.g. #622 Or maybe caliper...

[satota2]

Hi @jkneubuh,

PR #724 has landed and replaces the (closed / invalid) PR #684. Please proceed with the updates when you are ready...

OK. I would like to start with this updated code.

Deploying 1:1 chaincode to peer is a good start. Let's start with this approach, and re-visit if we have resource constraints.

Thank you for agreeing this.

Load-balancing chaincode is a longer thread, and we should probably start first...

Understood about the priorities. I thought that extending for monitoring etc. and supporting multi-namespaces (#644) were also considered important.