Module system consideration

[selfuryon]

Hi!
I was trying to make a vouch/dirk and lighthouse modules and got some thoughts about our module system:

• Special treatment of some args: we need to have special steps to work with some args (usually jwt)
• Some args are flags without value: it's hard to use them with freeformType because we need to special treatment for them, or we have to use extraArgs
• Args over settings: currently, we use args to get the desired state, but maybe in some situations we will need to use config files (ex, vouch, and dirk)
• Args settings live in the args section: it's not typical for other modules to use attrset for that

My suggestions:

• add an option for a special behavior: ex, to generate jwt token and put them in a special path, don't do that implicitly when we set some option to null (need to figure out how to do that).
• I like the settings approach: I usually expect this section in any modules to configure it. We can use it for all apps and configuration styles (config files or args)
• Use args option like a list
• for args, we can use that, but it seems like not a very common pattern, and we can rewrite it (personally, I don't like how it works with list type)

Examples:

prysm:

  services.ethereum.prysm-beacon.sepolia = {
    enable = true;
    openFirewall = true;
    jwt-secret.auto-generate = true;
    settings = {
      network = "sepolia";
      checkpoint-sync-url = "https://sepolia.checkpoint-sync.ethdevops.io";
      disable-grpc-gateway=true;
    };
    # In really args don't needed here because of freeform module, but anyway.
    args = [
      "--rpc-host=0.0.0.0"
    ];
  };

will be transformed to

beacon-chain --network=sepolia --jwt-secret=XXX --disable-grpc-gateway --checkpoint-sync-url="https://sepolia.checkpoint-sync.ethdevops.io" --rpc-host=0.0.0.0

vouch:

  services.ethereum.vouch.sepolia = {
    enable = true;
    openFirewall = true;
    settings = {
      beacon-node-addresses = ["localhost:4000" "localhost:5051" "localhost:5052"];
      timeout = "2s";
    };
    # we also don't need that due to freeform type and how viper works, but anyway
    args = [
      "--tracing-address=1.1.1.1:100"
    ];
  };

will be transformed to

vouch --base-dir=CONFIG_PATH_DIR --tracing-address=1.1.1.1:100

and vouch.yaml

beacon-node-addresses:
  - localhost:4000
  - localhost:5051
  - localhost:5052
timeout: "2s"

[selfuryon]

@aldoborrero @brianmcgee

[brianmcgee]

When first writing this I wasn't all that familiar with RFC 42 and the settings approach. Happy to re-work to match that as the means of configuration, but I would be careful about switching to using the config files and treat it on a case-by-case basis.

The reason why is I found the settings files for Geth and Prysm to be poorly documented, unusual for their chosen format, and generally difficult to work with. By contrast, the args were documented and less brittle to bind against. This was why I chose the args route, and making it explicit we were mapping against the args by naming the option args.

[aldoborrero]

@brianmcgee I think you're referring to poor implementation (or loose parsing) of TOML or YAML files, right?

[aldoborrero]

Otherwise, RFC42 in terms of standardization feels natural to me. I would propose creating issues related to each module and treating them individually to track effort and assign it to somebody.

[brianmcgee]

Yeah, there were some strange non standard uses of TOML and YAML that I encountered.

[selfuryon]

but I would be careful about switching to using the config files and treat it on a case-by-case basis

Yeah, I also like to manage CL/EL via args, it's really better documented. The idea was that it doesn't matter from the user's view what exactly we use: args or configs.

But I prefer args anyway, and I believe we should leave them with args:)

I will try to do lighthouse and vouch modules on this week using my thoughts. After we can discuss/fix to make them better.