customise jitsi interface

[Treebal]

Notre objectif était de ne pas avoir à rebuilder des images des composants jitsi, on ne change rien à ce niveau, on vient juste appliquer des surcharges, à l'image de ce que tu avais fait pour config.js. et interface_config.js on a ajouté dans le configmap jitsi-custom-config le title.html et le body.html pour maîtriser les métas données et des surcharges de style css.

On a aussi ajouté des samples d'instanciation et de configmap et une mini doc sur la démarche de customisation d'interface et comment builder son propre manager pour test : https://github.com/Treebal/jitsi-kubernetes-operator/tree/improve/custom_config_jitsi/config/samples https://github.com/Treebal/jitsi-kubernetes-operator/blob/improve/custom_config_jitsi/interfaceJitsi.md

[Fred-Treebal]

Overwriting the prosody lua config file is "proposed" , no change will be applied unless customProsodyConfigCM parameter is used in a jitsi instance definition. I agree this might indeed seem a bit intrusive, though some parameters like limiting the default number of participants in a room have no other form of configuration option, yet. This allows to still use default jitsi docker images for the 4 components web, jvb, jicofo & prosody. When a jitsi update is available, we propose to check for changes in the default prosody lua file and reapply your needed changes (like max participants)

Done : Removed DS_Store ... Rename this prosody conf file to customProsodyConfigCM to make it more generic.

[hrenard]

Yeah, I understand. I'm reluctant to add this because one of the goal of the operator is to abstract some/most of Jitsi's complexity. Ideally, it would allow people to deploy Jitsi without the need to understand it. For that to work, the operator needs to be in control. This kind of option bypasses the operator. And if we want the operator to enhance the upstream config, this option would introduce nondeterministic behavior. I think the best approach is to add our own config template in the operator and to expose options via the Jitsi CRD. But it means taking the responsibility of maintaining and testing the config (and some refactoring), and I don't have time to work on this right now. Another approach to allow deep customization would to be to add a way to inject environment variables by component (probably via ConfigMap and Secret) and use a custom image which leverage these variables. Do this makes sense ?

[hrenard]

Sorry for the long paragraph. It's probably too soon for this kind of decision to have any impact. And I probably do a big refactor someday. I need two things before merging :

• rebase or merge the main branch because the turn thing (in prososdy.go) has been removed since it's now in upstream parameters.
• re-run a make manifest to regenerate the jitsi-operator.yaml and avoid changing the formatting.

[hrenard]

I did some small changes, but it's now merged on master (see 31743bf41f8e2f0e5dfdb725c837a4767bd695f9). Thanks for the contribution !