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:
- [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
- [volumes] section: most clients are also gonna need to store some stuff on disk somehow
- how to resolve variables: e.g.
$L2OO_ADDRESS
? We need to make sure these vars are exported when we run the docker compose setup
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