In NS8 I assume this template system is no longer on board?
No, it isn’t. In NS8 each application can provide a way to customize its configuration or not. The beloved e-smith centralized configuration template system is not with us any more 
Some applications are still configured with traditional .conf or text files, some provide HTTP APIs. For this reason we didn’t use a single template system.
3 Likes
So every module is mostly a “snowflake” for the orchestrator to manage for config and… scr3w up.
Trust me it is a huge lost I think and I am still convinced that we need something to replace it but as @davidep pointed me and he is right we have a lot of cases to cover. The template system has been coded since more than 20 years and you cannot do it by a wave of magic wand. Morever esmith template is perl based and NS8 is python based, not really incompatible but different
However when you cut something to a developer he thinks how to turn around his issue and personally I recreated it with jinja2 template system but it is not integrated and you call an action that write the configuration file from a template file
Good news the conditionnal, the loop are integrated it was not true in esmith template
Maybe we need to document jinja template for other developers it could help
2 Likes
Other points against esmith system were that now we have a cluster we need a system aware to share its database with other nodes and able to trigger an event among the cluster when a module has got a change in its settings for other module elsewhere in the cluster that need to adapt their settings and restart their service. This is true with redis
One example, the smarthost settings, modules can register to the event smarthost settings and when you change it in the cluster-admin every module get the change and get the order to restart. When systemd restart the service, a discover service is triggered to find the new smarthost setting in redis local replica.
The inputs have changed with NS8 and really esmith was so old
2 Likes
Jinja2 is available in the core but does not suit every container.
In the container world a common configuration convention is passing parameters as environment variables, because the container entrypoint already provides the app configuration logic. (MySQL, Postgresql, Mattermost…)
In few cases you mount a .conf file or similar (Nginx, Dovecot, Postfix…)
A common third scenario is configuring also by API invocation (Webtop, Nextcloud, Mattermost…)
There is no way back to a one fit all solution.
However I understand the need of tuning some settings for some applications. In Samba, Mail, and wherever this is possible the correct procedure is documented in the module Readme files.
2 Likes
It is true
In the specific case of Nginx I could talk or other module like ejabberd and crowdsec we have environment variables but not for all cases and we need to write configuration files on the fly before the service starts
Hence I continue to think we need here an improvement like I find with jinja2. For simple template bash can do it too (echo, printf…)
R.I.P.
Is there no (configurable) time-out for the cluster-admin interface?
IIUC we discussed it here
1 Like