(Fix) add prefix to Sokol spec files

[igorbarinov]

Problem:
it's possible to make a mistake while working with two networks because similar file names
Solution:
add a prefix to sokol-
as is:

bootnodes.txt
spec.json
contracts.txt

to be:

sokol-bootnodes.txt
sokol-spec.json
sokol-contracts.txt

• rename files
• update instructions

this issue is for discussion. do you see any problems with renaming?

[phahulin]

To avoid exceptions, I'd propose to update playbooks to add this prefix on every network, so also core-bootnodes.txt, core-spec.json. This can also be joined with poanetwork/wiki#22 by moving toml files to playbooks as templates.

This would first need to be checked by updating existing nodes with old filenames on sokol.

[igorbarinov]

@phahulin is it in our pipeline?

[phahulin]

Yes, I guess we'll need another poa-devops playbook to update files on existing nodes

[6proof]

I think this is an great idea. Even if one were to manually download the wrong bootnode.txt file (download poacore-bootnodes.txt instead of sokol-bootnodes.txt to /home/bootnode/ - no issues as it can't accidentally overwrite the 'correct' version. Another poa-devops playbook means all nodes will have current net-name-bootnode.txt files, which solves another minor issue. Good work!

[phahulin]

@6proof which "another minor issue" do you mean?

[6proof]

By "another minor issue" I meant that not all nodes have up-to-date bootnodes.txt files. Issuing another poa-devops that pushes out changes requiring new naming convention (poacore-bootnodes.txt and sokol-bootnodes.txt for example) ensure that all nodes will have current information as of deployment of the new poa-dveops playbook.

John Le Gassic and I just today were discussing ways to keep bootnodes.txt files update on all nodes, and best way to push out new info to nodes. For example, when a new Sokol Network Validator is voted in through consensus, what is the system to 1. Verify the accuracy of the new node information -2. notify the active consensus nodes of the new participant so nodes can update bootnodes.txt and reload parity and netstat services.

On the same note, could use this system to temporarily sanction a non-compliant node during a Hard Fork by removing that node from consensus using same system. These are just discussions now. Perhaps this is already accounted for. Thanks for listening!

[igorbarinov]

It can cause a security issue on nodes of validators. I.e. when a c&c resource will be compromised, e.g., a GitHub account of POA Network

[6proof]

I agree, Igor. Interesting discussion.