search

fuseio / fuse-network

Fuse network engine; Contains instructions to connect as a node
MIT License
87 stars 45 forks source link

Network upgrade and fork #112

Closed Andrew-Pohl closed 3 years ago

Andrew-Pohl commented 3 years ago

Upgrade to OE 3.2.6, schedules a fork at block 14million.

Updated quickstart to easily update Nodes, Validators, BridgeValidators and bootnodes. Explorer nodes will need a manual DB update since we do not host any snapshots for explorer nodes.

Andrew-Pohl commented 3 years ago

Looks good. I understand now what's going on :) Can you explain the validator upgrade process?

Sure the upgrade process for node, bootnodes and validators is simple. I have added a new element into the .env file "CLIENT" this is used to tell the quickstart script what build to run OE or parity (defaults to OE). If this key isn't present in an env file (for existing users) it will assume that they are moving from parity->OE. As a result it will delete the existing DB and pull the new OE one from our S3 bucket. The S3 bucket is updated weekly so they will always be within 90k blocks of the head block (quick sync up).

For explorer nodes it's a little different since we don't host an archive DB stored on S3. OE have made a tool to upgrade databases which I have tested the quickstart will point users to this.

So for non explorer nodes it's simply download the new quickstart and run.

For explorer nodes it:

  1. Download new quickstart
  2. Stop running docker container
  3. Download DB upgrade tool
  4. (optional) back up existing DB
  5. Run tool on DB
  6. run quickstart
leonprou commented 3 years ago

Looks good. I understand now what's going on :) Can you explain the validator upgrade process?

Sure the upgrade process for node, bootnodes and validators is simple. I have added a new element into the .env file "CLIENT" this is used to tell the quickstart script what build to run OE or parity (defaults to OE). If this key isn't present in an env file (for existing users) it will assume that they are moving from parity->OE. As a result it will delete the existing DB and pull the new OE one from our S3 bucket. The S3 bucket is updated weekly so they will always be within 90k blocks of the head block (quick sync up).

For explorer nodes it's a little different since we don't host an archive DB stored on S3. OE have made a tool to upgrade databases which I have tested the quickstart will point users to this.

So for non explorer nodes it's simply download the new quickstart and run.

For explorer nodes it:

  1. Download new quickstart
  2. Stop running docker container
  3. Download DB upgrade tool
  4. (optional) back up existing DB
  5. Run tool on DB
  6. run quickstart

Sounds good, But I think the default for now (without having client) should be parity, so if Validators do not switch to OE without knowing. Need also to explain to them the upgrade process, and that some downtime is anticipated (right?). Idieallly when a validator is switching from parity to OE he would have some y/N prompt

Andrew-Pohl commented 3 years ago

Looks good. I understand now what's going on :) Can you explain the validator upgrade process?

Sure the upgrade process for node, bootnodes and validators is simple. I have added a new element into the .env file "CLIENT" this is used to tell the quickstart script what build to run OE or parity (defaults to OE). If this key isn't present in an env file (for existing users) it will assume that they are moving from parity->OE. As a result it will delete the existing DB and pull the new OE one from our S3 bucket. The S3 bucket is updated weekly so they will always be within 90k blocks of the head block (quick sync up). For explorer nodes it's a little different since we don't host an archive DB stored on S3. OE have made a tool to upgrade databases which I have tested the quickstart will point users to this. So for non explorer nodes it's simply download the new quickstart and run. For explorer nodes it:

  1. Download new quickstart
  2. Stop running docker container
  3. Download DB upgrade tool
  4. (optional) back up existing DB
  5. Run tool on DB
  6. run quickstart

Sounds good, But I think the default for now (without having client) should be parity, so if Validators do not switch to OE without knowing. Need also to explain to them the upgrade process, and that some downtime is anticipated (right?). Idieallly when a validator is switching from parity to OE he would have some y/N prompt

Good idea if they don't have CLIENT there I will add a y/n prompt to upgrade.

Andrew-Pohl commented 3 years ago

Looks good. I understand now what's going on :) Can you explain the validator upgrade process?

Sure the upgrade process for node, bootnodes and validators is simple. I have added a new element into the .env file "CLIENT" this is used to tell the quickstart script what build to run OE or parity (defaults to OE). If this key isn't present in an env file (for existing users) it will assume that they are moving from parity->OE. As a result it will delete the existing DB and pull the new OE one from our S3 bucket. The S3 bucket is updated weekly so they will always be within 90k blocks of the head block (quick sync up). For explorer nodes it's a little different since we don't host an archive DB stored on S3. OE have made a tool to upgrade databases which I have tested the quickstart will point users to this. So for non explorer nodes it's simply download the new quickstart and run. For explorer nodes it:

  1. Download new quickstart
  2. Stop running docker container
  3. Download DB upgrade tool
  4. (optional) back up existing DB
  5. Run tool on DB
  6. run quickstart

Sounds good, But I think the default for now (without having client) should be parity, so if Validators do not switch to OE without knowing. Need also to explain to them the upgrade process, and that some downtime is anticipated (right?). Idieallly when a validator is switching from parity to OE he would have some y/N prompt

Good idea if they don't have CLIENT there I will add a y/n prompt to upgrade.

Added in 98c63d5