Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ideas for additional configuration ... #4

Open
mbrandenburger opened this issue Jun 27, 2022 · 0 comments
Open

Ideas for additional configuration ... #4

mbrandenburger opened this issue Jun 27, 2022 · 0 comments

Comments

@mbrandenburger
Copy link
Contributor

The current sail syntax is nice ... here a few additional options I would find useful. Dumping my ideas here ...

chaincode:
    - name: asset-transfer
      version: v0.1.1
      image: my-chaincode-image:v1
      peers: [orgB-peer1, orgB-peer2, orgA-peer1, ...]
      channels:
        - name: mychannel
          policy: "OR('org1.member', 'org2.member')"

image: docker image name with tag. If no tag set, latest is used.
Either package or image is set.

peers: a list of peers where the chaincode is installed. What are the default peers?

Does it make sense to also define a set of "client nodes" equipped with the crypto material to run peer commands or deploy a fabric client sdk application?

What about setting FABRIC_LOGGING_SPEC for each peer or for all?

Oh and could we override certain keys in the core.yaml of a peer and the orderer.yaml?

What about enabling Idemix?

WDYT?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant