Onboarding / Automating Node deployment

+1 vote

Hi MC-Team,

would be great if you consider a better onboarding experience for new nodes that should join a existing network.

The problem here is (mainly when using docker, or other ways to automate nodes joining a network) that it is quite awkward at the moment to onboard a node.

When a node cannot join a network it just exits with a message.

To automate this I had to do a lot of scripting like:
- grep the account address (to hand it over to some node in the network for granting)
- start an additional rest service on the instance just to be able to query the account address from outside because the node immediately stops when not able (allowed) to connect
- hard to get the account address without again trying to connect and grep from the error message if you missed it
- do a bash for loop trying to connect every minute and see if permission were granted

I think dockerization of MultiChain and something like Multichain as a Service offerings need a better handling in this case.

Maybe the node can keep running and tries connect polling itself?

Maybe when it keeps running it has a minimal json rpc interface that allows to query:
- the generated MC account
- some information that are available event without connectivity to another network (e.g. which network it wants to join etc...)




asked May 18, 2017 by Alexoid

2 Answers

0 votes
Best answer

Thanks for this feedback. We're certainly aware that it would be better if the JSON-RPC API endpoint could stay up, even before the node has connected to the network for the first time.

In the meantime, a few ideas about how to make life easier:

  • For pure experimental purposes, if you use anyone-can-connect=true, then there is no need for nodes to be permissioned before they can connect to each other.
  • There is a runtime parameter -shortoutput which causes multichaind to output only the node address or wallet address (as appropriate) so you don't need to grep the output. You can tell the difference between the two scenarios by looking for the @ symbol.
  • Beta 2 will contain a feature whereby an initial private key can be passed to a node as a parameter when it is starting up, rather than the node self-generating its own random key (and address). This will enable connect permission to be pre-granted to the node, before it first connects. Of course you need to be comfortable with the key management implications of this.
answered May 18, 2017 by MultiChain
selected May 18, 2017 by Alexoid

I do something similar with our docker images, whereby I add address permissions to a running node and then import the private key to the new node for the given address when the docker container starts up.  (I use anyone-can-connect=true) to allow this.

For other features I've created feature specific keys.....so an address that has mining permission.  I then just load that key into any node that needs to mine.  That keeps things relatively simple.
+1 vote

Beta 2, just released, includes the initprivkey runtime parameter which lets a private key be provided to a node when it first comes online. It requires both that node, and the one it connects to, to be running beta 2.

answered Jun 15, 2017 by MultiChain
Sounds promising. I will see what I can get out of this. :-)