Add feature to include additional configuration files about sympa HOT 15 OPEN

There is another motivation: Concealing sensitive parameter cookie. To do it, currently permission of sympa.conf have to be dropped. I suppose at least this parameter should be separated.

My concern about inclusion feature is imcompatibility with edit_config feature (disabled by default): It seems to assume single configuration file.

from sympa.

from sympa.

Which edit_config feature?

As a listmaster, select "Listmaster admin" then "Edit robot config". The feature will be enabled by removing "&& removethistesttoenblefeature == '1'" in web_tt2/edit_config.tt2 template.

from sympa.

from sympa.

Funny, Soji invested a lot of effort into unifying sympa.conf and wwsympa.conf and now we want to split them again. ;-)
But now is is for good reasons...
As a matter of fact, Sympa configuration IS actually split into several files (edit_list.conf, auth.conf, trusted_applications.conf, etc.) even though they are not merged into a single entity when in memory.
So what you think about, Racke, would be to generalize the mechanims by which Sympa already uses several files?

for example: when configuring authentification, instead of accessing the auth.conf file, the code would access the "auth" part of the configuration which, in turn, the configuration code would find in the auth.conf file (or any other file name) ?

from sympa.

Sorry for cutting in.

I suppose most of *.conf (and at least any *.incl) may be unified into single config structure on memory. Once configuration became able to be dumped to single sympa.conf file [1], it may be easily chopped using such as include directive.

[1] A difficult point is that file format currently used is less expressive to represent complex structure, but it may be solved.

from sympa.

Yep. Which raise the question - again - about formalism.
sympa.conf is only simple key/values.
config are one level deep data structures.
A lot of people suggested to switch to a more widely known formalism such as JSON or YAML. I still don't know if it's relevant.

from sympa.

Which edit_config feature?

As a listmaster, select "Listmaster admin" then "Edit robot config". The feature will be enabled by removing "&& removethistesttoenblefeature == '1'" in web_tt2/edit_config.tt2 template.

OK, but it is necessary to break robot config in several parts? Or would that also edit the main sympa.conf?

from sympa.

That function is almost abandoned.

It stores changes in database instead of sympa.conf (I personally think we’d be better to give up config in database). Anyway we may not take care of it to talk about config inclusion.

from sympa.

Here is my private plan to extend format of sympa.conf / robot.conf.

It lacks directive to include other files. @racke, can you add such thing?

from sympa.

Yes, but first I have a question. If we are going to revamp the configuration as you suggest, wouldn't it make sense to switch to a common format like YAML? So we can use a parser on CPAN and it would be widely understood.

from sympa.

I do not have objection to use standardised format like YAML, JSON etc.

Only drawback with them is generic parser modules don't support inclusion. If it is settled, I prefer to them (my plan above is an alternative that is parsable by relatively simpler code without ready-made parser).

How do you think about popular format?

from sympa.

As I said I think it would be worth to use a standardized format, preferably YAML as is now common in many projects. Also with that we could use Config::Any it we think that would be beneficial.

For inclusion, there are several options:

• standard locations (e.g. sympa.d directory)
• command line flags
• environment variables
• even inline (e.g auth_include = /my/auth.include)

Also it is important to decide whether we do a deep or shallow merge.

Deep merge:

bounce.warn_rate 50 in an included file would only override the warn_rate and not the completely bounce namespace.

That turned out to be a nice feature in the Dancer configuration system.

from sympa.

Deep merge is the best on my opinion. I used it for sympa ansible project and will never leave it.
I agree with standardized format. However we need to migrate automatically previous instances from old formalism to the new one.
That includes handling lists templates and lists families.

from sympa.

I am sad that backtick syntax was removed before this feature has been implemented. I think backticks was primarily used for including values and now that is not possible anymore. :-(

from sympa.