Docker-jitsi-meet: Why does one want to "build config.js on each boot"

[tsproesser]

Since commit

https://github.com/jitsi/docker-jitsi-meet/commit/c149463823eddec60d5a96b76a05b7bf67b74bef

the web's config.js gets rewritten on every boot. Whats the idea behind this? I actually liked using configuration files instead of settings all values via environment variales. Now I have config files for all but web. That's a bit weird.

Edit: and where can I find some kind of documentation of env. variables available? E.g. p2p seams to be disable-able (since it is rendered in the bottom) but the example-file has no variable set for it.

[ludovicm67]

I think this comment could help you for what you want: https://github.com/jitsi/docker-jitsi-meet/issues/768#issuecomment-705536542.

You can find in the docker-compose.yml file all environment variables used per service under the environment key.

If you want to see defaults values for web environment variables, you can have a look at these two files:

• settings-config.js
• system-config.js

[tsproesser]

Guess "startAudioOnly" cant be configured via env vars, yet?

[saghul]

Whether you like it or not, this is the "container native" way of doing things. Almost everyone is surprised by the fact that the config is not regenerated on every container boot.

In c149463 we started the transition to this model, but it'll take a few passes until we cover everything.

[tsproesser]

But how about these two proposals:

1. Jitsi itself needs to handle EnvVariables e.g.: is variable set use it, else use config or
2. Just do not override the file if it exists? A clean container boots up every time you run the image. There is no need to overwrite it! If someone mounted a config file from outside the container he probably knows what he is doing and want to use this file?

[saghul]

We added a way for you to provide custom config, see: https://github.com/jitsi/docker-jitsi-meet/blob/master/web/rootfs/etc/cont-init.d/10-config#L72-L74 and for the JVB: https://github.com/jitsi/docker-jitsi-meet/blob/master/jvb/rootfs/etc/cont-init.d/10-config#L17-L19

[tsproesser]

Sorry, I really do not want to criticize someone here. Open source, everyone does it's best - all cool.

But I really don't see the reason for this effort! Variables needed to be handled by jitsi itself! This should not become a solution if the docker implementation trying to convert environment variables to config files. Everytime new properties drop in someone of the container-team needs to implement it. That's just unclean and error-prone.

Even if you do or need to handle it in the docker implementation that's ok. But there is no reason for implementing untransparent solutions for bringing in own config files. Just write it, if it does not exists! If one wants to mount the file from outside the container he probably knows what he is doing. I really don't see the need of some blackbox magic solution that just confuses people to the limit!

[saghul]

That's how it was from day one, because I thought the same way as you. But time has proven me wrong. Been there, done that, doesn't work.. You can't imagine how many bug reports we get where the answer is "delete your config so it's regenerated".

I hear you, but that's not how the container industry thinks, so it's better to compromise and build something that matches the expectations.

Arguably, there is an extra potential advantage: we could opt to change the config structure, and thanks to env vars the change would be transparent.

[tsproesser]

Ok, fair point. Makes me believe that the current solution is a _bit_ better than it was before. But knowing where we came from one version earlier makes this release probably kill most of the deployments out there. I guess many people are using the "latest" image and a redeploy killed most of their setups. How about just mentioning on the setup page "for the changes to take effect you need to redeploy docker-jitsi".

Never the less, the current solution can never lead to a fully satisfying one! You'll always need to choose between the devil and the deep blue sea. And you need to adopt the docker solution to every new variable being introduced. If you use your "extra config solution" you cannot rely on env. variables.

My recommendation would be: stop all your effort trying to solve the issue in the Docker container and make jitsi itself use the environment variables (env || config || default). I'd love to do it myself but I'm quite too busy (probably the most recent open source excuse out there, I'm sorry). If you really want this to become a clean reliable solution: stop generating config files, tackle the root cause. As you have already answered a feature request of mine (actually just closed it ;) ) in the jitsi repo you are a part of that team, too.

Love your great work! Keep it up! 👍