Produce config with any available field filled (even if defaults are acceptable) #17

New issue

Open

opened 2025-12-28 18:01:59 +00:00 by sami · 3 comments

sami commented

2025-12-28 18:01:59 +00:00

Owner

Originally created by @carpawell on GitHub (Jul 6, 2023).

Why do I think so?

It will be easier for me (a dev) to debug some deploys (look configs, see (understand) what version is running (if I see config_key: config_val, I do know what is happening if I do not see it, I try to recall every config value I have in my code and see what default it has and how it (its missing I mean) can affect the code)).
Defaults can change. Fixed explicit value can not change.
Same config template is easier to analyze (e.g. one deploy works, another does not, how do they differ?). Also, it is a common situation when an admin comes to a dev and asks about a config, so a dev should be able to see the difference easily.
If a value is not needed at all, let's drop it and not just skip it cause "it works well without it".
Understanding config is better than ignoring config. If an admin does not understand a certain parameter, it will be better (IMO) for him to figure its value (meaning) out, not drop it. It should help in the future.

@AnnaShaleva, @roman-khimov, @smallhive, @cthulhu-rider (devs who gonna see configs).

P.S. are default values so bad that they deserve an additional removal commit (time, attention, etc)?

Originally created by @carpawell on GitHub (Jul 6, 2023). Why do I think so? 1. It will be easier for me (a dev) to debug some deploys (look configs, see (understand) what version is running (if I see `config_key: config_val`, I do know what is happening if I do not see it, I try to recall every config value I have in my code and see what default it has and how it (its missing I mean) can affect the code)). 2. Defaults can change. Fixed explicit value can not change. 3. Same config template is easier to analyze (e.g. one deploy works, another does not, how do they differ?). Also, it is a common situation when an admin comes to a dev and asks about a config, so a dev should be able to see the difference _easily_. 4. If a value is not needed at all, let's _drop it and not just skip it cause "it works well without it"_. 5. Understanding config is better than ignoring config. If an admin does not understand a certain parameter, it will be better (IMO) for him to figure its value (meaning) out, not drop it. It should help in the future. @AnnaShaleva, @roman-khimov, @smallhive, @cthulhu-rider (devs who gonna see configs). P.S. are default values _so bad_ that they deserve an additional [removal commit](https://github.com/nspcc-dev/ansible-neofs-ir/commit/cd705ab7bd2bd7d308273bf7fe764266c6c2f50a) (time, attention, etc)?

sami commented

2025-12-28 18:01:59 +00:00

Author

Owner

@carpawell commented on GitHub (Jul 6, 2023):

If only I could add "question" and "discussion" labels in that repo...

@carpawell commented on GitHub (Jul 6, 2023): If only I could add "question" and "discussion" labels in that repo...

sami commented

2025-12-28 18:01:59 +00:00

Author

Owner

@cthulhu-rider commented on GitHub (Jul 6, 2023):

thinking about maintainability and convenience, i'd keep the config minimal in volume while saving the information transmitted from the admin to the application

thinking about dev research and reproduction, i'd have an auxiliary utility that takes a config as input and outputs the total values used by the application (with set defaults which were ommited). This utility could share the code with the application, and would give the developer confidence about the input which actually reached the program execution

imo this would be a good tradeoff between minimalism and visibility. In general, talking about configuration, i think admin UX >> dev's comfort. Developer can get docs with defaults and restore the final config by himself

but im very interested in other opinions, both devs and admins

@cthulhu-rider commented on GitHub (Jul 6, 2023): thinking about maintainability and convenience, i'd keep the config minimal in volume while saving the information transmitted from the admin to the application thinking about dev research and reproduction, i'd have an auxiliary utility that takes a config as input and outputs the total values used by the application (with set defaults which were ommited). This utility could share the code with the application, and would give the developer confidence about the input which actually reached the program execution imo this would be a good tradeoff between minimalism and visibility. In general, talking about configuration, i think admin UX >> dev's comfort. Developer can get docs with defaults and restore the final config by himself but im very interested in other opinions, both devs and admins

sami commented

2025-12-28 18:01:59 +00:00

Author

Owner

@smallhive commented on GitHub (Jul 7, 2023):

I don't mind and even like it when the config has not only default values but all possible values inside the config. Maybe even with comments. This config is a good starting point for configuration.

As an example, I want to show default PHP config. It has 2363 rows, including comments, default values, examples, etc.
From this example, you understand what you can adjust and how. How parameters affect the system. Default parameters always exist, but under comments, and you may use/change them easily.

Of course, in real life/production, such a big config isn't convenient and everyone uses a short version for 50-150 rows. These short versions describe very specific configurations for each installation.
Having fulfilled config really helps to make a shorter version.

In case we want to provide beginner config, we always may have some tutorial/separate config for each scenario. I mean next:

Look _Here_, you may start from only 25 rows of config to get a working configuration.
This installation suits, those who want to start with NeoFS, but don't know how.

If you are experienced and/or looking for a solution to your tasks:
- need more shards - see <here>, look at %SOME_TOPIC_NAME% in configurations
- want billions small files - see <here> and look <here>
- required thousands of 10TB+ files - see this example
- need ...

Any way full config with examples you may see <here>, read <this> and <this>

The main idea, I wanted to bring to the text is - config with defaults doesn't hide values and you know that some knobs exist

@smallhive commented on GitHub (Jul 7, 2023): I don't mind and even like it when the config has not only default values but all possible values inside the config. Maybe even with comments. This config is a good starting point for configuration. As an example, I want to show [default PHP config](https://gist.github.com/TheSunMan/4008090). It has 2363 rows, including comments, default values, examples, etc. From this example, you understand what you can adjust and how. How parameters affect the system. Default parameters always exist, but under comments, and you may use/change them easily. Of course, in real life/production, such a big config isn't convenient and everyone uses a short version for 50-150 rows. These short versions describe very specific configurations for each installation. Having fulfilled config really helps to make a shorter version. In case we want to provide _beginner_ config, we always may have some tutorial/separate config for each scenario. I mean next: ```Hey, do you want to use NeoFS storage, but don't know how? Look _Here_, you may start from only 25 rows of config to get a working configuration. This installation suits, those who want to start with NeoFS, but don't know how. If you are experienced and/or looking for a solution to your tasks: - need more shards - see <here>, look at %SOME_TOPIC_NAME% in configurations - want billions small files - see <here> and look <here> - required thousands of 10TB+ files - see this example - need ... Any way full config with examples you may see <here>, read <this> and <this> ``` The main idea, I wanted to bring to the text is - config with defaults doesn't hide values and you know that some knobs exist