Travis CI changed the way how we install docker - travis updated their basic image and add Docker via docker.list, so I've checked how addon instruction is working under the hood - this is just a tee to sources.list, so I've changed docker.list to have the latest stable Docker.
W: Target Packages (stable/binary-amd64/Packages) is configured multiple times in /etc/apt/sources.list:51 and /etc/apt/sources.list.d/docker.list:1
Proof from logs that docker is working now:
sudo apt-get -y -o Dpkg::Options::="--force-confnew" install docker-ce
...
The following packages will be upgraded:
docker-ce
1 upgraded, 0 newly installed, 0 to remove and 41 not upgraded.
Get:1 https://download.docker.com/linux/ubuntu jammy/stable amd64 docker-ce amd64 5:27.0.1-1~ubuntu.22.04~jammy [25.2 MB]
Preparing to unpack .../docker-ce_5%3a27.0.1-1~ubuntu.22.04~jammy_amd64.deb ...
Unpacking docker-ce (5:27.0.1-1~ubuntu.22.04~jammy) over (5:26.1.4-1~ubuntu.22.04~jammy) ...
Setting up docker-ce (5:27.0.1-1~ubuntu.22.04~jammy) ...
Test
Unit Test Coverage
Before:
<!-- copy/paste 'go test -cover' result in the directory you made change -->
After:
<!-- copy/paste 'go test -cover' result in the directory you made change -->
Test/Run Logs
Operational Checklist
Does this PR introduce backward-incompatible changes to the on-disk data structure and/or the over-the-wire protocol?. (If no, skip to question 8.)
YES|NO
Describe the migration plan.. For each flag epoch, describe what changes take place at the flag epoch, the anticipated interactions between upgraded/non-upgraded nodes, and any special operational considerations for the migration.
Describe how the plan was tested.
How much minimum baking period after the last flag epoch should we allow on Pangaea before promotion onto mainnet?
What are the planned flag epoch numbers and their ETAs on Pangaea?
What are the planned flag epoch numbers and their ETAs on mainnet?
Note that this must be enough to cover baking period on Pangaea.
What should node operators know about this planned change?
Does this PR introduce backward-incompatible changes NOT related to on-disk data structure and/or over-the-wire protocol? (If no, continue to question 11.)
YES|NO
Does the existing node.sh continue to work with this change?
What should node operators know about this change?
Does this PR introduce significant changes to the operational requirements of the node software, such as >20% increase in CPU, memory, and/or disk usage?
Issue
Travis CI changed the way how we install docker - travis updated their basic image and add Docker via docker.list, so I've checked how addon instruction is working under the hood - this is just a tee to sources.list, so I've changed docker.list to have the latest stable Docker.
Details on the failed build: https://app.travis-ci.com/github/harmony-one/harmony/jobs/623369799 Specifically:
Proof from logs that docker is working now:
Test
Unit Test Coverage
Before:
After:
Test/Run Logs
Operational Checklist
Does this PR introduce backward-incompatible changes to the on-disk data structure and/or the over-the-wire protocol?. (If no, skip to question 8.)
YES|NO
Describe the migration plan.. For each flag epoch, describe what changes take place at the flag epoch, the anticipated interactions between upgraded/non-upgraded nodes, and any special operational considerations for the migration.
Describe how the plan was tested.
How much minimum baking period after the last flag epoch should we allow on Pangaea before promotion onto mainnet?
What are the planned flag epoch numbers and their ETAs on Pangaea?
What are the planned flag epoch numbers and their ETAs on mainnet?
Note that this must be enough to cover baking period on Pangaea.
What should node operators know about this planned change?
Does this PR introduce backward-incompatible changes NOT related to on-disk data structure and/or over-the-wire protocol? (If no, continue to question 11.)
YES|NO
Does the existing
node.sh
continue to work with this change?What should node operators know about this change?
Does this PR introduce significant changes to the operational requirements of the node software, such as >20% increase in CPU, memory, and/or disk usage?
TODO