The network should be able to managed in a multihost manner

[anilhelvaci]

• Ca Nodes
  • [x] Ca Nodes should be able to register new users only and not enroll them
  • [x] Ca Nodes should include their internal IP in the csr.hosts when enrolling
• Peer Nodes
  • [x] Peer Nodes should be able to enroll to a remote ca node and store msp locally
  • [x] There should be another web service that creates the "fabrc-ca" folder and copies the root tls-ca-cert of the remote organization into the /client folder in the splash screen
  • [x] CouchDb config should be taken through constructor in order to connect to a remote couchdb instance
• Context DB
  • [x] Context DB should be kept updated (Check out service discovery for that) This is now being broken into smaller parts in #83
  • [x] Peer_Nodes table should be created
  • [x] internal_ip and external_ip should be removed from Base_Nodes table

[anilhelvaci]

During the azure test which there is 5 vms (1 for couchdbs, 1 for peers and 3 for organizations) fabric-installation-app was unable to install, approve and commit the chaincodes on the vms because the context was unaware of locations of the peers.

Good Solution

• Keep the context db updated in a manner that the app will always know about its peers

Workaround

• Write web service that receives the peer configuration via request body and act upon it

Should check

• The reason why the master machine(the one ca nodes being run) is installing the chaincodes is that only org admin has the authority to take such action right now. It would be good practice to check if the chaincode installation can be assigned to roles that are not org-admins.