I’m planning on changing the way Jibri configuration is implemented soon. There’s a PR here and a migration guide here that I’d be interested in feedback on. This code does not break Jibris with an “old” config file: it leverages the new jitsi-metaconfig lib to first check the old configuration and, if no value is found, check the new configuration.
Soon after that PR lands, Jibri will start logging warnings if “old” configuration is being used for parameters. Some (appropriate) amount of time later, exceptions will be thrown if old configuration is present. Finally Jibri will stop checking old config locations entirely.
The type of feedback I’m looking for:
Does the code in that branch properly respect your existing config?
Anything in the config migration guide that can be made clearer?
We are using static template, so basically config file format is irrelevant, we will set it up once and leave it be.
For the migration guide - some referenced files returns 404. I don’t know this format (never heard of) and its value encoding, so i would like to at least have some basic info about something like boolean values are true/false (or yes/no) and are case-(in)sensitive, strings needs to be in single/double quotes or can be both, how are special chars encoded, etc.
I opened a newtopic for an existing jibri environmet upgrade.
I found some things that may be helpfull for the community, and i have some questions myself, i would be glad if you could check it here Quests about Upgrading an existing Jibri Server