Introduce declarative CRDs for Fabric Topologies

[jkneubuh]

Fabric operations can be broken up into two phases:

1. Set up a network of services (nodes), consisting of CAs, Peers, and Orderers. The output of "phase 1" is a set of gRPCs service URLs.

2. Administer a Consortium of Organizations, Channels, and Chaincode contracts.

Step 2 above has traditionally been approached as an "imperative" process, based on scripting (e.g. bash - test-network), imperadeclarative (sic) hybrids such as ansible-collections, or GUI workflows such as fabric-operations-console.

This approach works, but it's not working very well for Fabric. Can we do better?

Can the logic of "admin fabric network" (step 2 above) be tamed, such that it is codified entirely in golang, and realized in fabric-operator? It's fine if there is some complexity for setting up Fabric networks. But can this complexity be implemented "in code," and bubble up to a set of declarative resource descriptions managed by the operator?

Idea:

1. Use fabric-operator to express CAs, Peers, and Orderers as K8s CRDs. (✅)
2. Extend fabric-operator, in conjunction with fabric-admin-sdk, such that the Fabric Topology is expressed and realized as declarative resources managed by the kube API controller?

The general idea is to provide a 100% declarative, Cloud-native approach for the full stack administration of Fabric, fully contained within golang code managed by fabric-operator. With this pattern of operations, a Fabric administrator can simply kubectl apply (or use a native SDK) a series of peers, orderers, channels, and chaincode Resources to the k8s API controller, delegating the burden of network construction entirely to the operator.

[jkneubuh]

Big question 1:

1. This implies that fabric-operator can be "taught" to administer a network. E.g. what is the "admin context" for the operator? How will the "org administrator" delegate authority to the operator, for some fixed amount of time, to achieve some configuration goal?

[jkneubuh]

Big question 2:

2. A Consortium is an aggregate of multiple sub-networks, each under management by disparate organizations.

This is not a philosophical question about the nature of Fabric's decentralized ledger. Practically it means that a "network" will be under management by multiple parties, and must SPAN different Kubernetes clusters. How will this work, if "the operator" is really a set of "the operators," needing to coordinate across multiple clusters?

Hint: Channel is not a singular CRD. There needs to be a differentiation between ChannelOrganizer (creator / consortium organizer) Leader and ChannelSubscriber Joiner

[danielpenagos]

What each operator could be autonomous is regarding the amount of peers the organization could have. To have this question answered we need to split the problem in two different ones: what is an organization be able to define without asking the others(because we are not affecting the topology) and second what kind of operations we could perform but it's scope is at the consortium level. In other words:

• consortium level operations: add orderers, add anchor peers, add channels, add organizations.
• organization level operations: add peers.