anton-rs/op-up

feat: Component TOMLs

Opened this issue · 5 comments

Description

The op_config crate offers a Config TOML that allows you to configure the OP Stack.

While this is useful for stack-wide configuration, op-up needs component-level TOML configs.

TOML is the config of choice to enable for configuration parsing into native rust so configs can be used as a library. This is a backwards-compatible alternative to defining custom dockerfiles for each component, and will allow for #3.

To make the TOMLs backwards-compatible, a field should allow for component TOMLs to reference base docker images or local Dockerfiles.

The TOML could look like the following

[metadata]
name = "challenger-go"
version = "1.1.2"

[command]
git = "git@github.com:ethereum-optimism/optimism.git"
# Default test hardhat deploy key - not safe for production environments
deployer = "ac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80"

[docker]
# The remote docker url will be tried first to fetch the container.
remote = "<remote dockerhub container url>"
# If the remote field is not set, or the fetch fails, the local dockerfile will be referenced.
local = "./Dockerfile.challenger-go"

# Below are inlined docker-file specific fields that are only used if the above remote or local fields are not specified.

[docker.build]
base = "golang:1.19.0-alpine3.15"
dependencies = [
    "make",
    "gcc",
    "musl-dev",
    "linux-headers",
    "git",
    "jq",
    "bash"
]
run = "make op-challenger GOOS=$TARGETOS GOARCH=$TARGETARCH"

[docker.exec]
base = "alpine:3.15"
command = ["/bin/sh", "/op-challenger-go-entrypoint.sh"]

[flags]
l1-eth-rpc = "http://l1:8545"
rollup-rpc = "http://rollup-client:8545"
l2oo-address = "$L2OO_ADDRESS"
dgf-address = "$DGF_ADDRESS"

LMK what y'all think @clabby @merklefruit. I'm not sure I like the inlined docker fields, but not sure as of yet how to do better.

Looks good already! Just a few thoughts:

  1. [ports] section: ideally opup will find non-colluding ports in a smart way, but in a first version it's fine to have them manually in the toml files imo
  2. [volumes] section: most clients are also gonna need to store some stuff on disk somehow
  3. how to resolve variables: e.g. $L2OO_ADDRESS? We need to make sure these vars are exported when we run the docker compose setup

It might also be a good idea to check out the Bollard container Config struct to see what are the pieces needed to start a container, since we'll probably have to parse the TOML into one of these.

More context in #39

What do you think about putting the components in the same toml config but different keys? One key per op component

[challenger]
[[metadata]]
name = "challenger-go"
version = "1.1.2"

[[command]]
git = "git@github.com:ethereum-optimism/optimism.git"
# Default test hardhat deploy key - not safe for production environments
deployer = "ac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80"

[[docker]]
# The remote docker url will be tried first to fetch the container.
remote = "<remote dockerhub container url>"
# If the remote field is not set, or the fetch fails, the local dockerfile will be referenced.
local = "./Dockerfile.challenger-go"

# Below are inlined docker-file specific fields that are only used if the above remote or local fields are not specified.

[[docker.build]]
base = "golang:1.19.0-alpine3.15"
dependencies = [
    "make",
    "gcc",
    "musl-dev",
    "linux-headers",
    "git",
    "jq",
    "bash"
]
run = "make op-challenger GOOS=$TARGETOS GOARCH=$TARGETARCH"

[[docker.exec]]
base = "alpine:3.15"
command = ["/bin/sh", "/op-challenger-go-entrypoint.sh"]

[[flags]]
l1-eth-rpc = "http://l1:8545"
rollup-rpc = "http://rollup-client:8545"
l2oo-address = "$L2OO_ADDRESS"
dgf-address = "$DGF_ADDRESS"

hmm I guess it would become quite long with a lot of containers, not sure which way is best