Use default file for config.yml

[ostcar]

As we discussed, when I want to rebuild the docker-compose.yml, I first remove it and then call openslides setup for the same directory.

But I also have to remember to set --config config.yml.

Would it be possible, that if the folder exists and there is a file with a special name, then it is automaticly used as config? For example openslides.yml?

[ostcar]

Sry, I accidentally opened the issue in the backend. It was for the openslides-manage-service

[normanjaeckel]

Hm. I don't like such implicit stuff. In this case it must be configurable so that someone may have such a file and does not want to use it. I think this is too much complexity for this rare case. Most users with small meetings should use the default and then customized the docker-compose file by hand.

[ostcar]

Please don't encourage people to manually edit the docker-compose file. On the contrary, you should add a Do not edit header.

When a user changes the file and then recreates it after an update or after changing the config, all manual changes will be lost. If they should change the file, you have to implement some sort of diff-mechanism, that merges the manual changes.

I had the problem with the issue #145 . After each change of the config, I had to manually change the docker-compose file again. This was annoying.

Especially users with small meetings and not so much knowledge should only edit the simple config.yml instead of the powerful docker-compose.yml. It will be very hard to debug issues, when users have there individual docker-compose files. But it will be kind of easy if they have there own config.yml

[normanjaeckel]

Hm. What about using a docker-compose.override.yml?

[funkyfuture]

then @ostcar and me would have to remember to extend the arguments to each call of docker-compose.yml accordingly. also one would need to keep track of changes to the generated docker-compose.yml and update overriding definitions.

my outsider perspective is:

• this tool is intended to generate a stringent docker-compose.yml
• an implicit consequence is that there's one project folder per OpenSlides instance
• it makes sense to expect an instance specific configuration file there, exactly there
• thus calling the tool with pointers to the project folder and the config file is just redundant

[funkyfuture]

i've been thinking and actually, using extending/overriding configuration files w/ Docker-Compose is the proper way to go. but that also means:

• the "DO NOT EDIT THIS FILE"-header proposed by @ostcar is necessary in the generated config
• the additionalContent configuration must be removed as it duplicates functionality
• the documentation needs to elaborate on this; an examples folder w/ overriding configurations can demonstrate various use-cases
• it might be useful to define variables in an .env file instead of relying on YAML's anchor/alias-feature, so that the overriding compose file can use commonly defined variables

this is slightly off-topic for this issue (and doesn't add any argument regarding the initial proposal), but in the end the questions are culminating in the user experience. shall i open a separate issue in this regard?