Support managing https://github.com/matrix-org/matrix-user-verification-service for a Jitsi deployment

https://github.com/vector-im/jitsi-helm/tree/openshift exists but hasn't been merged. Investigate whether it can be safely merged for non-OpenShift deployments and do so if it can be.

Current latest Docker release as per https://github.com/jitsi/docker-jitsi-meet/releases

Whilst this repo has stopped being a fork, we should still add credit (prominently) in the readme for https://github.com/krakazyabra/jitsi-helm which did the initial development

Describe the bug
From version 0.50.0, cannot update or fresh deploy through Kubeapps, setting or not custom configmaps.
Is there any configmap not listed in default yaml that must be defined? In previous versions runs perfectly.

To Reproduce
Steps to reproduce the behavior:

1. Deploy/update on Kubeapps.
2. Fill/change yaml definitions as you need, or maintain if you are updating.
3. Press "deploy 0.50.X" button
4. Kubeapps show error:
   "An error occurred: Unable to create the installed package for the package "vector-im/jitsi" using the plugin "helm.packages": rpc error: code = Internal desc = Unable to create helm release "appname" in the namespace "example": Release "appname" failed and has been uninstalled: rendered manifests contain a resource that already exists. Unable to continue with install: could not get information about the resource ConfigMap "" in namespace "example": resource name may not be empty"

Expected behavior
It should be deployed with no errors as in previous versions.

Screenshots

Desktop (please complete the following information):

• OS: OSX 13.4
• Browser: Safari

Additional context
Deploying onto k8s 1.25 and 1.26 with same error.

To improve the monitoring situation, we should give the option to configure ServiceMonitors for all pods with metrics endpoints that this chart manages.

VictoriaMetrics also supports these CRDs

Currently we have

createSecret: true
JICOFO_AUTH_PASSWORD: ""
JICOFO_COMPONENT_SECRET: ""
JVB_AUTH_PASSWORD: ""

With either requires an external secret to be created/managed or those 3 values to be provided with secrets. #6 did this because we were getting in situations where the secrets were changing every deploy but only some deployables were being restarted (and so picking up the new secret values) leading to situations where the running deployables were using different password values.

Look at https://helm.sh/docs/topics/charts_hooks/ to see if that will help with secret generation inside the chart again. But more generally we should look at specifying a secret name & key that contains these values, e.g. the Bitnami redis chart has:

Using the above scheme we could generate a password on initial install only if neither of the top 2 is set

This will be important if we want to do #29 or #30.

Making changes to web's custom config should force a restart of the web pods.

Requiring a helm command to be run (e.g. config hash label/annotation) rather than running a reloader sidecar is acceptable

• Proper versioning in Chart.yaml for the chart and Jitsi itself
• Create tags for releases rather than referring to individual commits
• Automation to turn a tag/release into a Helm chart repo
• Generate changelog and upgrade notes

Error: INSTALLATION FAILED: execution error at (jitsi/templates/web-deployment.yaml:8:23): One of PUBLIC_URL or ingress.hosts must be provided

some igress host error

please help me anybody

Support managing a fleet of Jibris with this chart

• Linting
• Documentation for values.yaml with something like https://github.com/norwoodj/helm-docs
• Testing?

https://github.com/vector-im/jitsi-helm/blob/main/templates/_helpers.tpl#L22-L37 defines a helper for adding a set of common labels but it isn't used.

Consult https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/ to ensure all the recommended labels are set consistently everywhere