Comments (17)
nicolapaoli
commented on August 18, 2024
1
@nicolapaoli to complete yaml structure for dev, qa and prod examples
from nephos.
nicolapaoli
commented on August 18, 2024
1
Proposed dev configuration structure:
core:
# Comment out to make it work on your cluster
cluster: minikube
# ChartMuseum repository or directory holding charts
chart_repo: stable
# Directory where we hold configtx.yaml
dir_config: ./examples/dev/config
# Directory where we hold:
# 1) cryptographic material
# 2) genesis block and
# 3) channel transaction
# Directory where we hold crypto-material
dir_crypto: ./examples/dev/crypto
# Directory where the Helm Chart values reside
dir_values: ./examples/dev/helm_values
cas: {}
msps:
OrdererMSP:
namespace: orderers
org_admin: ordadmin
# org_passwd: # Set implicitly
orderers:
domain: orderers.svc.cluster.local
msp: OrdererMSP
names:
- ord1
secret_genesis: hlf--genesis
peers: {}
PeerMSP:
namespace: peers
org_admin: peeradmin
# org_passwd: # Set implicitly
orderers: {}
peers:
domain: peers.svc.cluster.local
msp: PeerMSP
names:
- peer1
channels:
mychannel:
channel_name: mychannel
channel_profile: MyChannel
secret_channel: hlf--channel
# You can specify a particular version of a chart for each chart used, or use the latest by default
versions:
postgresql:
hlf-ca:
kafka:
hlf-ord:
hlf-couchdb:
hlf-peer:
hl-composer:
Proposed qa configuration structure:
core:
# Comment out to make it work on your cluster
cluster: minikube
# ChartMuseum repository or directory holding charts
chart_repo: stable
# Directory where we hold configtx.yaml
dir_config: ./examples/qa/config
# Directory where we hold:
# 1) cryptographic material
# 2) genesis block and
# 3) channel transaction
dir_crypto: ./examples/qa/crypto
# Directory where the Helm Chart values reside
dir_values: ./examples/qa/helm_values
cas:
ca:
namespace: cas
# If testing locally on Minikube, we use our own self-signed certificate's PEM
tls_cert: ./examples/ca-nephos-local.pem
# Alternatively, if testing on a cluster with proper DNS and cert-manager...
#tls_cert: ./nephos/extras/Lets_Encrypt_Authority_X3.pem
msps:
OrdererMSP:
ca: ca
namespace: orderers
org_admin: ordadmin
# org_passwd: # Set implicitly
orderers:
domain: orderers.svc.cluster.local
msp: OrdererMSP
names:
- ord1
secret_genesis: hlf--genesis
peers: {}
PeerMSP:
ca: ca
namespace: peers
org_admin: peeradmin
# org_passwd: # Set implicitly
orderers: {}
peers:
domain: peers.svc.cluster.local
msp: PeerMSP
names:
- peer1
channels:
mychannel:
channel_name: mychannel
channel_profile: MyChannel
secret_channel: hlf--channel
# You can specify a particular version of a chart for each chart used, or use the latest by default
versions:
postgresql:
hlf-ca:
kafka:
hlf-ord:
hlf-couchdb:
hlf-peer:
hl-composer:
Proposed prod configuration structure:
core:
# Comment out to make it work on your cluster
cluster: minikube
# ChartMuseum repository or directory holding charts
chart_repo: stable
# Directory where we hold configtx.yaml
dir_config: ./examples/prod/config
# Directory where we hold:
# 1) cryptographic material
# 2) genesis block and
# 3) channel transaction
dir_crypto: ./examples/prod/crypto
# Directory where the Helm Chart values reside
dir_values: ./examples/prod/helm_values
cas:
ca:
namespace: cas
# If testing locally on Minikube, replace this with your own self-signed certificate's PEM
tls_cert: ./nephos/extras/Lets_Encrypt_Authority_X3.pem
msps:
OrdererMSP:
ca: ca
namespace: orderers
org_admin: ordadmin
# org_passwd: # Set implicitly
orderers:
domain: orderers.svc.cluster.local
msp: OrdererMSP
names:
- ord1
secret_genesis: hlf--genesis
kafka:
name: kafka-hlf
pod_num: 4
peers: {}
PeerMSP:
ca: ca
namespace: peers
org_admin: peeradmin
# org_passwd: # Set implicitly
orderers: {}
peers:
domain: peers.svc.cluster.local
msp: PeerMSP
names:
- peer1
- peer2
channels:
mychannel:
channel_name: mychannel
channel_profile: MyChannel
secret_channel: hlf--channel
# This is only used when we implement a Composer network
composer:
name: hlc
secret_bna: hlc--bna
secret_connection: hlc--connection
# You can specify a particular version of a chart for each chart used, or use the latest by default
versions:
postgresql:
hlf-ca:
kafka:
hlf-ord:
hlf-couchdb:
hlf-peer:
hl-composer:
from nephos.
nicolapaoli
commented on August 18, 2024
1
Good point, we might want to improve the name of the Organisations in the examples before or after this migration, as in the current ones we have 2 Organisations:
- OrdererMSP which has orderers, but no peers
- PeerMSP which has peers, but no orderers
They could have orderers and peers themselves tho, this naming was just a convention. It's like having Org1MSP and Org2MSP.
from nephos.
inzamam-iqbal
commented on August 18, 2024
1
@alexvicegrab Ok so I will use the older format. Shall I use opts['msps'].keys() to get the msps and then use those keys to access the msps in that way we will get both the advantage of dictionary and also we will be able to let the user define any number of msps with any name?
from nephos.
inzamam-iqbal
commented on August 18, 2024
1
@nicolapaoli so for now (for solo and kafka) can we always assume AlphaMSP has the orderer?
from nephos.
inzamam-iqbal
commented on August 18, 2024
@nicolapaoli proposed config structure allows peers inside OrdererMSP and orderers inside PeerMSP, but under msps key why don't we make the OrdererMSP and PeerMSP as list? so that users can have any name for them? also then they can specify any number of orgs too?
from nephos.
inzamam-iqbal
commented on August 18, 2024
@nicolapaoli yeh we can change the examples to somethinglike org1MSP and org2MSP. But we have to change the msps to a list. I mean it should be something like
msps:
- OrdererMSP:
ca: ca
namespace: orderers
org_admin: ordadmin
# org_passwd: # Set implicitly
orderers:
domain: orderers.svc.cluster.local
msp: OrdererMSP
names:
- ord1
secret_genesis: hlf--genesis
kafka:
name: kafka-hlf
pod_num: 4
peers: {}
- PeerMSP:
ca: ca
namespace: peers
org_admin: peeradmin
# org_passwd: # Set implicitly
orderers: {}
peers:
domain: peers.svc.cluster.local
msp: PeerMSP
names:
- peer1
- peer2
Because if we have it as a list we can let the users use any name for the msps. We can iterate over msps, we can get msps like opts["msps"][0].
If we don't use the list we can't let them change the name as they want. Also if we let them to define multiple msps list will make more sense.
from nephos.
nicolapaoli
commented on August 18, 2024
Yep, good call @inzamam-iqbal . I am happy with that.
Let's have @alexvicegrab to have a look at it as well, then we can implement this after #12 and #13 .
from nephos.
alexvicegrab
commented on August 18, 2024
I like it overall, but I would prefer the older format where the MSPs are not lists. The reason why, is that we will need to go through each list to find the appropriate MSP, whereas in the old version, a dict allows immediate (and easy) finding of the MSP by its short alias.
We can still have a name field in each MSP, with a more detailed, explicit string name.
from nephos.
alexvicegrab
commented on August 18, 2024
In terms of naming, we could have names for the MSPs such as AlphaMSP, and BetaMSP, so that we transition later to the case where we use Raft and (eventually) full BFT, and each MSP has its own orderer or set of orderers.
from nephos.
inzamam-iqbal
commented on August 18, 2024
@alexvicegrab @nicolapaoli so after the change each component in the msp should belong to same name space unlike now where all peers belong to one ns and all orderes belong to another ns. am I correct?
from nephos.
inzamam-iqbal
commented on August 18, 2024
@alexvicegrab @nicolapaoli is there any advantage in adding msp under peers and orderes? Peers and Oerderes are already under msps? I mean the
opts["msps"]["OrdererMSP"]["orderers"]["msp"]
msps:
OrdererMSP:
ca: ca
namespace: orderers
org_admin: ordadmin
# org_passwd: # Set implicitly
orderers:
domain: orderers.svc.cluster.local
msp: OrdererMSP
names:
- ord1
secret_genesis: hlf--genesis
kafka:
name: kafka-hlf
pod_num: 4
peers: {}
from nephos.
inzamam-iqbal
commented on August 18, 2024
@nicolapaoli @alexvicegrab Based on my readings, I think in the case of orderers we don't have to add support to distribute it to multiple orgainzations in the case of kafka. Because anyway we can have only one kafka cluster for a network. So all the orders have to contact the same kafka cluster. Because of that for kafka even the recommended way is to have one org to have the orderes. But we can add that support to Raft ordering service.
For now my suggestion is to
- have one organization with the name OrdererOrg, then we can have many organizations for peers with any names we want
from nephos.
nicolapaoli
commented on August 18, 2024
#14 (comment) - Yes not there yet with Kafka, but definitely we want to have structure ready to support multiple orgs.
Good point on #14 (comment), let's take msp away from ords and peers.
Let's add a name field on each MSP as suggested here #14 (comment)
Let's change Org names from Orderer and Peer to Alpha and Beta as suggested here #14 (comment) (This could be a separate issue before if helps)
For prod, we'll have something like:
core:
# Comment out to make it work on your cluster
cluster: minikube
# ChartMuseum repository or directory holding charts
chart_repo: stable
# Directory where we hold configtx.yaml
dir_config: ./examples/prod/config
# Directory where we hold:
# 1) cryptographic material
# 2) genesis block and
# 3) channel transaction
dir_crypto: ./examples/prod/crypto
# Directory where the Helm Chart values reside
dir_values: ./examples/prod/helm_values
cas:
ca:
namespace: cas
# If testing locally on Minikube, replace this with your own self-signed certificate's PEM
tls_cert: ./nephos/extras/Lets_Encrypt_Authority_X3.pem
msps:
AlphaMSP:
ca: ca
name: AlphaMSP
namespace: alpha
org_admin: alphaadmin
# org_passwd: # Set implicitly
orderers:
domain: alpha.svc.cluster.local
names:
- ord1
secret_genesis: hlf--genesis
kafka:
name: kafka-hlf
pod_num: 4
peers: {}
BetaMSP:
ca: ca
name: BetaMSP
namespace: beta
org_admin: betaadmin
# org_passwd: # Set implicitly
orderers: {}
peers:
domain: beta.svc.cluster.local
names:
- peer1
- peer2
channels:
mychannel:
channel_name: mychannel
channel_profile: MyChannel
secret_channel: hlf--channel
# This is only used when we implement a Composer network
composer:
name: hlc
secret_bna: hlc--bna
secret_connection: hlc--connection
# You can specify a particular version of a chart for each chart used, or use the latest by default
versions:
postgresql:
hlf-ca:
kafka:
hlf-ord:
hlf-couchdb:
hlf-peer:
hl-composer:
from nephos.
nicolapaoli
commented on August 18, 2024
Exactly, let's specify that (the scenario) on README for each examples
from nephos.
alexvicegrab
commented on August 18, 2024
Yes, almost perfect. I'd enhance it like this:
AlphaMSP:
ca: ca
name: AlphaMSP
namespace: alpha
org_admin: alphaadmin
# org_passwd: # Set implicitly
orderers:
domain: alpha.svc.cluster.local
nodes:
ord1: {}
ord2: {}
secret_genesis: hlf--genesis
kafka:
name: kafka-hlf
pod_num: 4
from nephos.
alexvicegrab
commented on August 18, 2024
And for the peers, it would get more interesting:
BetaMSP:
ca: ca
name: BetaMSP
namespace: beta
org_admin: betaadmin
# org_passwd: # Set implicitly
orderers: {}
peers:
domain: beta.svc.cluster.local
nodes:
peer1: {}
peer2: {}
channels:
foochannel:
msps:
- BetaMSP
channel_name: foochannel
channel_profile: "Channel for Foo"
secret_channel: hlf--foochannel
barchannel:
msps:
- BetaMSP
channel_name: barchannel
channel_profile: "Channel for Bar"
secret_channel: hlf--barchannel
from nephos.
Related Issues (20)
- Failed to create new connection: context deadline exceeded on pytest integration on MacOS Minikube
- Docker image HOT 2
- Update .format() function to f strings.
- Investigate the use of PyHelm to replace the execution of helm via subprocess. HOT 2
- Currently we only support one single channel in nephos_config.yaml HOT 1
- Add OWNERS file so maintainers are auto-added as reviewers to all PRs HOT 1
- Review and correct log levels for messages.
- Improve Composer input_files call messaging
- Integration tests need to be more robust on Travis CI
- [Cleanup] Remove example certs and add documentation
- Add "hf.Registrar.Roles" attribute controls.
- PostgreSQL helm chart upgrade HOT 3
- Pre Multi-Org nephos version failing when no MSP is defined
- PyPi woes? HOT 2
- check_id() function returns True even when "fabric-ca-client identity list" request fails HOT 1
- [UPDATE] cert-manager apiVersion and acme files HOT 1
- Failed to create channel if peer ingress enabled HOT 2
- Fabric 2.0 support HOT 1
- [Fabric] Update repository to use Fabric 2.0
- Dependabot couldn't authenticate with https://pypi.python.org/simple/
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from nephos.