You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using the IRB example, not specifically to critique IRB, but it's a more fully formed example
General: My working assumption is that this is point in time statement of the overall structure
network:
name: irb
domain: localho.st
# what is namespace? it might be confusing with a namespace associated to a chaincode
namespace: test-network
On the above, A Fabric Network can exist across multiple cloud providers, and potentially across multiple domains. For example the Ansible collection has support for multi-zone setup. Common Channels and Orderers, but the peers aren't in the same.
On organizations that come next, I can see a case where some organizations don't want to share exactly how many peers they have.
I think a description of 'clients' here is a potential mistake. I'm seeing this as client applications; it's not the job of this file to describe the client network. What I think should be here is someway of specing the information that client applications will needed.
Basically, the connection profile, including CAs etc. what does a client need to connect
Like the inclusion of the version as that then permits a description of the network to be written in a new file, that for example Ansible can then migrate.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Using the IRB example, not specifically to critique IRB, but it's a more fully formed example
General: My working assumption is that this is point in time statement of the overall structure
On the above, A Fabric Network can exist across multiple cloud providers, and potentially across multiple domains. For example the Ansible collection has support for multi-zone setup. Common Channels and Orderers, but the peers aren't in the same.
On organizations that come next, I can see a case where some organizations don't want to share exactly how many peers they have.
I think a description of 'clients' here is a potential mistake. I'm seeing this as client applications; it's not the job of this file to describe the client network. What I think should be here is someway of specing the information that client applications will needed.
Basically, the connection profile, including CAs etc. what does a client need to connect
Like the inclusion of the version as that then permits a description of the network to be written in a new file, that for example Ansible can then migrate.
Lot more channel options but they can be added here I'm sure.
Being able to just point at something and say that's the chaincode is good
Beta Was this translation helpful? Give feedback.
All reactions