[RFC]: Configuration Overhaul

[0x009922]

I think this place is the most convenient to gather the team's feedback.

Checklist

• Internal review
• Library authors & users review
• Tech writers review
• DevOps review

---

Moved here: hyperledger-iroha/iroha-rfcs#3

[Erigara]

Don't have any objections.

[0x009922]

Addressed all of the comments as of now. The document looks finalised.

[Mingela]

good research of the all potential cases 👍 wondering if there is other behavior for other combinations of the parameters etc 😱

[6r1d]

I think a regular deployment with multiple SDKs making test requests to Iroha will help answer your question.
The configuration will change, and knowing what is broken early is essential.

If (for example) Tuesday's stand-up starts with the automatic news about the dev, stable or lts issues, it'll help both respond to the community (we know the actual state) and quickly resolve the potential problems.
(I am not sure triggering it only on each release is valid because Docker may change and influence the behavior of Iroha deployment.)

[Mingela]

to preserve the same behavior in using both ENV and FILE we should just get rid of using default values if nothing is specified at all, otherwise a user might use an outdated ENV var not knowing why the option is not applied (falling back to the default), and Iroha obviously shouldn't scan all outdated ENV vars to produce a warning about that (which can be done easily with a file)

[0x009922]

I am confused, because the purpose of default values is exactly to be applied when nothing is specified at all.

As for accidentally having an outdated ENV var, this RFC includes defining a deprecation policy. According to it, when an ENV var renaming takes place, the user will have a window between versions when they will get a warning/error for the deprecated variable before it is deleted entirely.

[Mingela]

In that case we should at least specify what fields have default values, I guess such a set should be as little as possible (i.e. log level etc only)

[0x009922]

Hmm, from internal discussions I remember the opposite request: we should have as many defaults as possible.

Anyway, on the configuration reference writing stage we will decide in details which fields we should have, what default values should be etc. At that stage we will also collect feedback from external users.

[6r1d]

In my opinion, both of you have a point.
I have a question regarding the deployment workflow (which may be covered by a part of the RFC and I'm missing something).
Let's assume a person who never used Iroha 2 performs the deployment.
How do they see the configuration parameters that were applied as defaults?
Maybe a verbose-running mode would help debug the deployment configurations at a later point.

[Mingela]

@mversic the suggestion is definitely valid, though we still have to determine what parameters should not be allowed to have the default value, e.g. things like metadata size limit could be risky if a user starts a network without proper attention to the consequences of not configuring that specifically to their use case or constraints.
On the other hand, if someone migrates to a newer version of Iroha, updating the corresponding configuration to match that is not a decision making factor overhead (esp. compared to a blockstore migration).

To conclude, I'd not insist on my view, either choice is fine to me. If we allow the defaults we just should be much more careful about this for every parameter now and in the future.

[0x009922]

@Mingela, do I get you correctly: your point is that there are more parameters which should be provided by the user than we have now?

In other words, configuration like metadata size limits should be defined by the user anyway.

[mversic]

we can always decide post factum on the set of parameters that will be required vs the ones that will have a default

[Mingela]

do I get you correctly: your point is that there are more parameters which should be provided by the user than we have now?

In other words, configuration like metadata size limits should be defined by the user anyway.

@0x009922, I'm afraid I'm not entirely aware of all the parameters which have defaults, but in my opinion things like metadata limits should be described in the docs properly and left up to a user.

I've just come to another idea to consider which is to introduce a config mode, i.e. strict vs relaxed (or like advanced/basic) based on which a user may omit specifying many parameters (prohibiting or enforcing defaults) keeping that decided by them still. On the other hand, we probably should not complicate things that much..

[0x009922]

things like metadata limits should be described in the docs

Everything should no doubt be described in the docs!

strict vs relaxed

It might be convenient. Let's leave this discussion to the stage of the actual documentation reference creation. It will be the best time to make decisions based on what might be the best for users.

Also, I had an idea of having extends mechanism. With it, users might extend existing presets. For example:

extends = "./base.toml"
# or even some built-in preset?
extends = "built-in:strict"

extends mechanism plays well with the "Trace Configuration Resolution" section.

[Mingela]

how about yaml alternative proposal?
common for deployments

[0x009922]

Well, choice between TOML and YAML is more about a personal preference, I believe. However, we prefer TOML primarily because:

• Simple and explicit syntax, more readable
• Strong types, less unexpected results
• Indentation doesn't matter
• Better error messages
• It is a standard for Rust ecosystem

As for making YAML/JSON/whatever an additional configuration format, it might badly affect the overall quality of the configuration system due to it being more generalised, thus e.g. less able to provide some details in error messages.

[mversic]

IMO TOML is the simplest of the three and is best suited for Iroha purposes

[Mingela]

My main motivation is that configuration is rather related to deployment, whereas TOML is common for a project (development) configuration in Rust, though I don't deny there deployment tools relying on TOML may exist. DevOps input may be really valuable here.

[6r1d]

While my current position is unrelated to DevOps, I'm confident I have enough experience to discuss DevOps issues.

For me, TOML is more readable, and the advantage of JSON/YAML/TOML is that we learn them quickly as human beings.

If we assume that people are configuring Iroha, they either know TOML or will know it as soon as they need to use it.
If we assume we're using GPT to configure it (for some reason), it knows the format and will most likely get stuck on the variable names. Real people may make the same mistake unless they have the config reference doc for the latest Iroha version with a lot of examples.

whereas TOML is common for a project (development) configuration in Rust, though I don't deny there deployment tools relying on TOML may exist

TOML is intended to be a configuration file format, according to Tom Preston-Werner at https://toml.io/en/:

A config file format for humans.

TOML aims to be a minimal configuration file format that's easy to read due to obvious semantics. TOML is designed to map unambiguously to a hash table. TOML should be easy to parse into data structures in a wide variety of languages.

[mversic]

IMO yaml is unnecessarily complicated and it's a mess to deal with spaces. JSON would be fine except that it doesn't support comments, and we really want to be able to comment out parameters in the config file. On the other hand, TOML fits our needs perfectly

if you look at mysql.conf it's configuration format is quite similar to TOML.

[Mingela]

lgtm

[Cre-eD]

LGTM

[0x009922]

The RFC is moved here:

• Configuration Overhaul RFC iroha-rfcs#3