Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bridge deployment to target nodes #19

Closed
akolotov opened this issue Feb 13, 2018 · 12 comments
Closed

Bridge deployment to target nodes #19

akolotov opened this issue Feb 13, 2018 · 12 comments
Assignees
Labels

Comments

@akolotov
Copy link
Contributor

akolotov commented Feb 13, 2018

It is necessary to develop a procedure and corresponding automation to easily deploy bridge on several nodes.

Key points

  1. It is necessary to provide ability to deploy bridge contracts as a separate step of the process. Results of this step: contract addresses for HomeBridge and ForeignBridge, block numbers where these contracts were deployed.
  2. Another step should allow easily generate configuration and database files for particular bridge instance. Most sensitive information is:
    • accounts which are used to communicate to the nodes (home.account and foreign.account)
    • communication channel with the node (home.ipc, home.required_confirmations, home.poll_interval, home.request_timeout, foreign.ipc, foreign.required_confirmations, foreign.poll_interval and foreign.request_timeout)
  3. bridge process must be run as a service on target system.
  4. Logs must be enabled by default, redirected to a file, log rotation must be configured.
@akolotov akolotov added the to do label Feb 14, 2018
@phahulin
Copy link
Contributor

@igorbarinov
Copy link
Member

igorbarinov commented Feb 19, 2018

@phahulin please move the card to in progress https://waffle.io/poanetwork/parity-bridge

@phahulin
Copy link
Contributor

@igorbarinov I get Only collaborators can update cards., looks like missing some permissions

@igorbarinov
Copy link
Member

@phahulin please try again

@phahulin
Copy link
Contributor

@akolotov I have a few questions

  1. could you describe how authorities should be used? At the present moment examples are not too descriptive because they use the same account simultaneously for home, foreign and 3xauthorities. I suppose this is not a general case and accounts can be different. In general situation, where should authorities' keys be placed?

  2. bridge's config toml contains parameters like required_signatures, required_confirmations, accounts, if we run multiple instances of the same bridge, they should be initially synchronized across instances. But what would happen if they get out of sync later? e.g. on one instance required_signatures==2 but on another instance required_signatures==1

@akolotov
Copy link
Contributor Author

@phahulin

  1. Currently we will assume that authority on particular bridge matches with the account which is used by the client Parity connected with the Foreign chain. Later, when we introduce RPC ((Feature) Add support to communicate with networks by RPC #4) connectivity between the bridge and chains, we will disconnect Parity accounts and bridge authorities: Parity clients could be run without necessity to unlock accounts, the bridge authority will be a separate account which signs transactions and send them through RPC to chains.

  2. Let's consider the config file. I will add comments to every line/section,.

estimated_gas_cost_of_withdraw = 0 <--- Should be the same on every bridge

[home] <--- Should be configured for every bridge separately
account = "0x842eb2142c5aa1260954f07aae39ddee1640c3a7" 
ipc = "/home/koal/parity/PoA_home/jsonrpc.ipc"
required_confirmations = 0
poll_interval = 2
request_timeout = 360

[home.contract] <--- Needed only on the deployment stage
bin = "contracts/HomeBridge.bin"

[foreign]<--- Should be configured for every bridge separately
account = "0xf3ee321df87781864f46f6464e764c2827fca73b"
ipc = "/home/koal/parity/PoA_foreign/jsonrpc.ipc"
required_confirmations = 0
poll_interval = 2
request_timeout = 360

[foreign.contract] <--- Needed only on the deployment stage
bin = "contracts/ForeignBridge.bin"

[authorities]  <--- Needed only on the deployment stage
accounts = [
	"0xf3ee321df87781864f46f6464e764c2827fca73b"
]
required_signatures = 1

[transactions] 
home_deploy = { gas = 3000000, gas_price = 18000000000 } <--- Needed only on the deployment stage
foreign_deploy = { gas = 3000000, gas_price = 18000000000 } <--- Needed only on the deployment stage
deposit_relay = { gas = 1200000, gas_price = 18000000000 } <--- Should be the same on every bridge
withdraw_confirm = { gas = 3000000, gas_price = 18000000000 } <--- Should be the same on every bridge
withdraw_relay = { gas = 3000000, gas_price = 18000000000 } <--- Should be the same on every bridge

Those parameters which are the same for all bridges is very useful to store in the contract and extract every time when the bridge is started. It will help them synchronize from one place and we will make sure that are the same on every setup.

@akolotov
Copy link
Contributor Author

akolotov commented Feb 21, 2018

Actually we need to differentiate several different scenarios of deployments: deployment for developers needs and production deployment.
DEV is actually two scenarios:

  1. Deploy parity and bridge services, configure dev chains with parity, deploy a token contract and configure the bridge contracts, install artefacts to manage transactions
  2. Deploy bridge service, use current parity configuration, deploy a token contract and configure the bridge contracts, install artefacts to manage transactions

PROD is as described above

  • Deploy bridge service, use current parity configuration, use already deployed contracts of bridge and recommended configuration.

Could you preapare a note to describe possible ways to implement this as a playbook?

@phahulin
Copy link
Contributor

I propose the following scenario

  1. single repository with same service definitions (roles) and same full set of available options for all playbooks
  2. multiple playbooks that differ in preset options

Example:
just for illustration let's imagine that there are only 4 options, in reality there will be more:

  • home_chain_json: url - which chain spec json to use on home side
  • foreign_chain_json: url - which chain spec json to use on foreign side
  • deploy_contract: bool - should playbook automatically deploy contract
  • db_toml: string - path to local file db.toml to copy to the bridge server

Now we can have dev.yml playbook that run all services, and have the following preset options (they will be stored in group_vars/dev.yml file)

home_chain_json: "https://.../poanetwork/dev-bridge-chains/.../home.json"
foreign_chain_json: "https://.../poanetwork/dev-bridge-chains/.../foreign.json"
deploy_contract: yes
db_toml: ""

Users create hosts.yml file:

---
dev:
  hosts:
    192.0.2.1::
      ansible_user: ubuntu

run this playbook via ansible-playbook -i hosts.yml dev.yml and deploy a ready-to-go configuration. They don't need to provide any additional options themselves (only server ip and ssh username). However, should they need to change some options, e.g. they want to use kovan as foreign-side, they can still do so by setting foreign_chain_json in hosts.yml:

---
dev:
  hosts:
    192.0.2.1::
      ansible_user: ubuntu
      foreign_chain_json: "https://github.../paritytech/.../kovan.json"

options set in hosts.yml overwrite those in group_vars/*

In the same way we can create prod.yml playbook that don't have certain steps (e.g. contract deployment), configuration file group_vars/prod.yml will be shorter

home_chain_json: "https://github.../poanetwork/.../core.json"
foreign_chain_json: "https://github.../ethereum/.../foundation.json"

and users will have to provide db_toml option in hosts.yml (since they are attaching to an existing bridge)

---
prod:
  hosts:
    192.0.2.1::
      ansible_user: ubuntu
      db_toml: "/home/joe/db.toml"

then they can run playbook via ansible-playbook -i hosts.yml prod.yml

Advantages of this setup imo are that

  1. we don't create multiple repositories, instead sharing the same codebase
  2. we'll be able to create additional preset configurations in the future (not only poa-mainnet bridge but maybe others)

Concerns that I have at the moment:

  1. this scenario needs to be tested, current playbook rewritten a little (add more options, separate certain steps so that they can be added or removed independently)
  2. not clear what "use current parity configuration" means - who and to what extent will prepare that configuration, shouldn't it be done by the playbook?
  3. details of deployment process may depend on other issues and will change when those issues are getting closed

@akolotov
Copy link
Contributor Author

Thanks Pavel (@phahulin) for good explanation.

Regarding parity configuraion - yes, the playbook should have an option to depoy parity config as well since it is related to spec of the corresponding chain.

Yes, deployment process depends on other issues. Could you point out most critical ones?

@phahulin
Copy link
Contributor

It's a bit hard to tell, because I have to guess implementation details and some of them are interconnected. From my best understanding

  1. these are the issues that will require changes:
  1. changes that should have a minor impact (config files mostly)

@akolotov
Copy link
Contributor Author

Bridge deployment is under separate repo: https://github.com/poanetwork/deployment-bridge

@ghost ghost removed the in progress label May 20, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants