separate agd build process from runtime files

[dckc]

What is the Problem Being Solved?

Our work with agd to date involves building from source: git clone ...; yarn && yarn build and the like.

We have yet to document a result from the build process that can be copied from a build host to a deployment host.

Description of the Design

Perhaps a tarball that could be installed in /usr/local similar to installing go?

We would have to identify the necessary set of files. Perhaps the built agoric-sdk directory suffices? But agd itself typically goes in ~/go/bin; would that be a post-unpack step?

Which platforms to support? How portable is the result of a yarn build?

stretch goal

• support unattended installation with tools such as cosmovisor.

Security Considerations

This would reduce some risk involved in the yarn && yarn build step, which relies on various scripts from npm to be well-behaved. We do have checksums in our yarn.lock file that give reasonable assurance that the same scripts we routinely run in ci and development would be run by customers.

Test Plan

Build a release artifact and try it out in places like a blank ubuntu docker container.

[dckc]

One emerynet upgrade participant reported:

We are using Cosmovisor and we changed the daemon_name. The only error we got is due to panic: exec: "ag-chain-cosmos": executable file not found in $PATH

In fact, it is declared as

export PATH=$PATH:/usr/local/go/bin:$GOBIN:$HOME/go/bin

One likely cause: $HOME had one value at build time, but a different value at runtime.

Another advised:

symlink is not good idea. incase of we compile new version, it'll crush old version. We should have control on the binaries.

Someone else reported a work-around:

Added this line to systemd file

Environment="PATH=/home/ubuntu/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/home/ubuntu/agoric-sdk/packages/cosmic-swingset/bin"

[mhofman]

The node.js side is probably going to be the most difficult, especially since we rely on native addons which are not very portable.

Given our need for runtime bundling, and 3rd party executable like xsnap worker, it's likely a self extracting based approach such as caxa would be needed.

[dckc]

... native addons which are not very portable ...

The norm, I gather, for validator software releases is to have a separate package for each platform... at this point, basically: linux or mac. And if we only provided a binary on one platform to start, that would be something.

by way of example, proposal 12:

{
  "binaries": {
    "linux/amd64": "https://github.com/Agoric/ag0/releases/download/agoric-upgrade-7/ag0-agoric-upgrade-7-linux-amd64?checksum=sha256:e99081066fd5e25035dabb1e1e870757a9eb618a440c04fdbcc12c27774c9e4c",
    "linux/arm64": "https://github.com/Agoric/ag0/releases/download/agoric-upgrade-7/ag0-agoric-upgrade-7-linux-arm64?checksum=sha256:24aa17821977ed5634db1ace3e7839a22dfa34dabaad14abfb15338935221616",
    "darwin/amd64": "https://github.com/Agoric/ag0/releases/download/agoric-upgrade-7/ag0-agoric-upgrade-7-darwin-amd64?checksum=sha256:25fbd14eb2b853f51af88882c055f6e403f847b6c19972953ead002a3b98f02c",
    "windows/amd64": "https://github.com/Agoric/ag0/releases/download/agoric-upgrade-7/ag0-agoric-upgrade-7-windows-amd64.exe?checksum=sha256:2590c742dd6ba2e67b8ad9333821935fa7b1b5cd9527f05504e51f9351826d49"
  }
}

[mhofman]

I am not sure how portable some of the node addons are between linux versions. I do remember running into issues between Ubuntu/debian major versions, probably because of some dynamically linked libraries.

[dckc]

In a cosmic-swingset meeting today, we agreed to de-emphasize the "binary" goal and emphasize the goal of building on one host and deploying on another.

[dckc]

standard Tendermint installation process: make install

This would be handy for https://restake.app/agoric?about=ledger

The standard Tendermint installation process is detailed below, but you might need to check the documentation for project specific install.

git clone https://github.com/Agoric/agoric-sdk/ restake_agoric
cd restake_agoric
make install

[dckc]

a cosmovisor approach to pismoC

In preparation for the pismoC upgrade on emerynet (prop 13), kjnodes shared https://services.kjnodes.com/testnet/agoric/upgrade
Some others appreciated it.

Making a copy of the script here for future availability:

# Clone project repository
cd $HOME
rm -rf pismoC
git clone https://github.com/Agoric/agoric-sdk.git pismoC
cd pismoC
git checkout pismoC

# Install and build Agoric Javascript packages
yarn install && yarn build

# Install and build Agoric Cosmos SDK support
(cd packages/cosmic-swingset && make)

# Prepare binaries for Cosmovisor
mkdir -p $HOME/.agoric/cosmovisor/upgrades/agorictest-upgrade-9/bin
ln -s $HOME/pismoC/packages/cosmic-swingset/bin/ag-chain-cosmos $HOME/.agoric/cosmovisor/upgrades/agorictest-upgrade-9/bin/ag-chain-cosmos
ln -s $HOME/pismoC/packages/cosmic-swingset/bin/ag-nchainz $HOME/.agoric/cosmovisor/upgrades/agorictest-upgrade-9/bin/ag-nchainz
cp golang/cosmos/build/agd $HOME/.agoric/cosmovisor/upgrades/agorictest-upgrade-9/bin/
cp golang/cosmos/build/ag-cosmos-helper $HOME/.agoric/cosmovisor/upgrades/agorictest-upgrade-9/bin/

[dckc]

FYI, @michaelfig is making progress on cosmovisor support in #7037.

It takes a different approach than the goal here; it refines the process of building on the validator machine, rather than separating the build process from installation.

[dckc]

closely related:

• Document procedure for isolating and relocating build artifacts #6574

[dckc]

@michaelfig your recent work looks like it addresses this, which is cool. Is there more to do here? Or should we close this?

• build(cosmos): make Node.js addon tolerate relocation #7865

[michaelfig]

recent work looks like it addresses this

I suggest pointing at the following, which is true of master and will be true for the next release taken from master after mainnet-1b:

After agoric-sdk/bin/agd build, the Git-cloned agoric-sdk directory is self-contained (see CAVEAT). You can transfer or move that directory to another location, and as long as your validator runs agoric-sdk/bin/agd (or a symlink to that script within the SDK) it will continue to work without needing a rebuild.

CAVEAT: the built agoric-sdk directory will still have a runtime dependency on Node.js.