Update a jitsi-meet shard without service downtime

Hello,

I know that Videobridges can be shut down gracefully, and they can also be removed and added gracefully. Therefore, upgrading them with no downtime is doable.

How do we upgrade the jitsi-meet main services (Jicofo and Prosody) with no downtime? They run on a separate machine in my case.

The only way I imagine to achieve this is:

  • Have two shards (shard #2 is already running the latest software and has no active meetings, while shard #1 needs software upgrade but has many active meetings).
  • Have a web proxy which dynamically starts to route new meetings to shard #2.
  • When a meeting ends at shard #1, notify the web proxy that this room is closed and new requests for the same room must go to shard #2.
  • Wait until all meetings on shard #1 are over.

Is there an easier way? Is this how you do it at meet.jit.si?

This is pretty much what we do on meet.jit.si. There’s no expicit notification that a conference ended. Instead the proxies have their own timeout.

Boris

1 Like

Thank you. This is a complicated approach.

What happens if we just suddenly replace the whole shard with a new one? How will browser and mobile clients react? Will they hiccup for a few seconds and automatically reconnect, or all participants will need to manually rejoin the conference (noticing that our service went down)?

If you are fronting the service with haproxy and you suddenly replace the shards, all the clients will see a reload screen with small timeout and will reload joining on the new shard on the same room name.

3 Likes

Is there guide that we could follow to implement this ? Specifically this part. :

  • Have a web proxy which dynamically starts to route new meetings to shard #2.
  • When a meeting ends at shard #1, notify the web proxy that this room is closed and new requests for the same room must go to shard #2.
  • Wait until all meetings on shard #1 are over.

thanks

This is what haproxies do for us, the fact that nobody access that room on shard1 for 5mins that entry timeouts and is deleted and because shard1 is in drain mode new meetings for the same room name will go to shard2 which is ready and operational.