Service configuration: single global config or service-specific

[mzabaluev]

Moved from #385 (reply in thread)

One thing that we still need to break out is how we want config files to be stored. That is, do we want multiple configs, a single config with a global namespace, etc. There's a single-source of truth vs. modularity tradeoff here.

Problems

• Tradeoff between single source of truth and modular configuration.
• Mixing up of settings for different services. Example: m1-da-light-node-util conflates settings for the light node with settings for the full node to connect to the light node.

[mzabaluev]

@radupopa369 can provide an insight from the cloud infrastructure perspective.

From the code organization standpoint, once we make configs hierarchical as discussed in #384, it's a simple change to switch from a global Suzuka config to service-specific structures it's made of, they would be ready to serialize.

Looking more abstract, there may be some remote configuration backend where accessing a sub-namespace to configure the specific service may be problematic.

[l-monninger]

What would think of a solution where we program lookups into format? For example, the m1-da-light-node config field in Suzuka could be a lookup to a given file.

This is more complex, but it keeps us from creating multiple sources of truth, while still maintaining service specific files.

Cyclical lookups would need to be detected.

[mzabaluev]

What would think of a solution where we program lookups into format?

I'd like to understand how exactly should this look programmatically.

Currently, a protocol unit receives a borrow of its specific config from a top-level structure (e.g. SuzukaConfig) that is parsed from the entire config file. So, we separate load/parse and configuration phases and the entire configuration data model is first loaded in memory.