Feature/all config

[berkes]

This allows all jitisi-meet-config variables to be set from within this role.

I probably removes the need to install jitisi-meet-config deb package; and removes the need to run debconf on that, but since we move the file generated there, into a backup, we do create a nice reference.

Please let me know if you wish me to remove debconf setup and the installation of that package.

[cimnine]

Thank you for your PR.

I like the idea, that the Ansible role can be used to configure Jitsi. What I don't like about your approach is that the maintainers of this role (currently mainly me) would have to keep the settings and the defaults in sync with every release of Jitsi Meet.

Hence I would prefer a solution which would still allow Jitsi to be configured in the Ansible role, but which would not require the synchronization work.

I was thinking that, instead of replacing them altogether, some kind of patching of the files that ship with the jitisi-meet-config would have to take place.

What's your opinion on this?

[berkes]

I am not familiar enough with ansible to know whether patching a json file is stable and practical. But I did see this is possible.

My ansible "philosophy" in my environments, is that there's always only one canonical source of a file: I dislike merging files from various sources. I avoid "lineininfile" as much as possible, have very bad experiences with "blockinfile" etc.
Personally, I want to know exactly who is providing the entire file and generally simply copy it over as template into my projects: to avoid conflicts, duplication, syntax errors and so on.

This is why I chose the current setup, where I to leave it to the implementor; the user of your role; to provide the proper variables: I simply render the entire struct provided by the user, as JSON.

I understand your point about having to keep the "config" in sync with jitisi, so, My personal preference aside:

Would you prefer to have me rewrite this with:

• lineinfile
• Use jq to patch the file: https://stackoverflow.com/a/53546229/73673
• Use ansible-jsonpatch: https://github.com/ParticleDecay/ansible-jsonpatch
• Or, use something else?

[cimnine]

I see your points. And I like your argument.

What about a compromise here? We'll add a flag, let's say jtisi_manage_config: true|false.
If it's true, then it's this roles' job to manage the config.

By default, jtisi_manage_config would be false. But if it's true, the following would execute:

- when: jitsi_manage_config|bool    # check for jitsi_manage_config
  name: Configure Jitsi
  import_tasks: jitsi/config.yml

This way, we don't have to follow upstream, because by default, we don't mangle with what comes by default from upstream.

But it's still possible to configure the configuration using this Ansible role.

(Btw, I'm not particular happy with the variable name jitsi_manage_config. I've also thought about jitsi_managed_config or jits_config_management. Feel free to choose either or propose your own.)

[berkes]

Good idea and very clear.

I will implement this, but am a bit busy, so it might take a few days before it lands in this PR.

As for the name: For now i'll go with use_custom_jitsi_config_vars because that is not a double negative (pun intended), and it is a clear instruction to both the reader of the vars and to the roles: "use this instead of that".

[berkes]

@cimnine : I've implemented your suggestion and documented this behaviour in README.

[cimnine]

Thanks for the updated PR. I really like the documentation part! I have left some comments. Feel free to leave a message wherever you disagree.

Could you also add the use_custom_jitsi_config_vars (or whatever it will be called) to the ## Role Variables section in the beginning of the README.md? And a short text that tells the reader to find more information further below.

[cimnine]

Looks good. I'll merge when I'm not as tired as I am now.