[core] Update cli tool for incentivenet

AquiGorka commented 2 months ago

default points to "production" (which is going to be arbitrum testnet)
identify the error when gcp is not around so that we can document it before people reach out to us
add a --devnet flag that points to devnet (aws)
maybe some way to auto upgrade the cli or maybe at least let people know they are not in the latest version (be mindful, not every single command, maybe once every N hours)

bgins commented 2 months ago

Our Goal

Our goal is to make it as simple as possible to switch networks when using the CLI.

The run command would use testnet by default (until mainnet):

lilypad run cowsay:v0.0.4 -i Message="moo"

An additional network option would set the network to devnet or dev:

lilypad run cowsay:v0.0.4 -i Message="moo" --network devnet

Proposal: Embed per network configs into the binary

We could embed configs with contract addresses for each network. The configs would be embedded directly into the binary as an embed.FS.

The network would be selected with a network option:

testnet. Contract addresses for testnet. (default)
devnet. Contract addresses for devnet.
dev. Contract addresses for local development.
(eventually we would add mainnet which would become the default)

We may add other values to the config like rpc_url. The configs would be in a standard format so we could extend for custom configs read from file. I propose TOML below.

Precendence

The configs would be used last after command line options and environment variables. The precedence would go:

CLI options. Should always take precedence because it is the user explicitly tweaking a configuration.
Environment variables. Should come second as a mechanism for dynamic configuration.
(Config file. Future work, but we could read configs from file using the same format as the embedded configs.)
Embedded configs. Should come last as default values when no other configuration has been provided.

Benefits

Embedding would give us an easy way to switch networks, but it would have a few additional benefits:

Nearly zero config for the most common use cases.
- Private keys can't be done this way. We will likely need some environment variables or config files for them.
We could track deployed contracts by release. Each time we change contract code, we update the embedded configs and bump the version.
- When helping users debug, we could ask them which CLI version they are using and instantly know which contracts they are using. (May have to check if the have environment variables set or if they used CLI options.)
- We probably want to auto-update the CLI. With auto-updates, we could usher users into using the newest contracts without asking them to make config changes.

Tradeoffs

We would need to be disciplined about updating the config files every time we change the contracts. We might be able to automate.

Impact on other services

The solver, resource-provider, job-creator, and mediator all use the same mechanism for loading contract addresses. The run command instantiates a job-creator to run a job.

We probably want all services to use the embedded configs. That way we can version the services alongside the CLI. But we could use the embedded configs only for the run command with some refactoring.

Again, none of this will have an immediate impact because the environment variables we use today will override the embedded configs.

Alternatives

We could provide environment files or config files with the contract addresses per network:

Extra steps for users. UX isn't as nice.
Would have to implement config files if we wanted those.

We could inject contract addresses into user environments using Doppler:

Would need to think about Doppler access. Maybe something like Doppler service accounts would be appropriate.
Doppler ain't cheap.

Proposal: TOML

TOML would be a good choice for the configuration format. With an acknowledgement that there may be bikeshedding, here is how I would compare with the other popular formats:

JSON. Not really a good configuration language. Lack of comments without additional support for example.
YAML. More powerful and complex than we need. We won't need to re-use blocks for example.

Also, TOML is configs are mostly flat which makes it quite readable in my opinion. Here's a more thorough comparison if folks are interested: https://www.anbowell.com/blog/an-in-depth-comparison-of-json-yaml-and-toml

Private keys

We obviously can't use this approach for private keys or any other sensitive material. TBD what to do here. Open to ideas.

Migration from GCP

Once we shut down our GCP testnet, we may have users with environments that point to the old contracts.

We could embed a config with the GCP contracts and warn the user that they need remove the environment they were using, which will move them to the new testnet without configuring anything.

Probably the CLI should do nothing until they have cleared out their environment?

We can eventually drop this check from our code base.

richardbremner commented 2 months ago

LGTM.

I've also like to see a command to output the config actually being used.

Lilypad-Tech / lilypad