Support for prosody pod lifecycle hook

[anirbandas18]

We extended the default prosody chart with the "container lifecycle" configuration

• Add the needed lifecycle configuration:

# ../charts/jitsi-meet/charts/prosody/templates/statefulset.yaml
spec:
  template:
    spec:
      containers:
          lifecycle: {{ toYaml .Values.lifecycle | nindent 12 }}


# ../charts/jitsi-meet/charts/prosody/values.yaml
lifecycle: {}

# ../charts/jitsi-meet/values.yaml
prosody:
  lifecycle: {}


# Configure pod lifecycle hooks as follows
prosody:
  lifecycle:
    postStart:
      exec:
        command: ["/bin/sh", "-c","echo Hello from the postStart handler > /usr/share/message"]
    preStop:
      exec:
        command: ["/bin/sh","-c","nginx -s quit; while killall -0 nginx; do sleep 1; done"]
`

[spijet]

Hello @anirbandas18!

Thank you for the idea, I'll think about adding it to the chart. One small question, though: why do you try to kill nginx in Prosody pod when it's not used there? 😅

[anirbandas18]

We figured out that prosody stores reserved conferences in memory. This is a problem when prosody pods restart because it no longer remembers the reservations it had, so does not call the delete conference by id API endpoint if the reservation manager, thereby keeping the reservation in an inconsistent state.

[anirbandas18]

My sample is just an example to include placeholders for lifecycle hooks in prosody pods

[spijet]

We figured out that prosody stores reserved conferences in memory. This is a problem when prosody pods restart because it no longer remembers the reservations it had, so does not call the delete conference by id API endpoint if the reservation manager, thereby keeping the reservation in an inconsistent state.

Can you please open an issue and describe the problem in more detail? I'll try to reproduce it and maybe ask Prosody developers for help.

[anirbandas18]

I don't think Prosody developers can help much here because it is not a Prosody issue per se but how it is interpreted in the Jitsi reservation system implementation. For us it's a problem because of how we implement our use cases around managed reservations. Moreover, it's root cause lies in the mod_reservartions.lua script which is part of the jitsi community Prosody plugin where in the reserved conferences are managed within prosody in an in-memory map and not in a persistent data store. You can refer to this link on my discussion with the OG prosody maintainers about this issue and the final words from their side.

[anirbandas18]

To replicate this, follow the steps:

• Setup Jitsi reservation system
• Enable reservation in Prosody for Jitsi
• Reserve a conference in Prosody via the reservation system
• Start the reserved conference in Jitsi Meet
• Observe the POST /conference call made from Prosody to reservation system and take note of the conference state maintained against the generated conferenceId in the reservation system
• Intentionally kill Prosody pod if in kubernetes or Prosody container if in docker-compose or Prosody process if in vanilla Linux while reserved conference is still in progress in Jitsi Meet
• Notice that there is no DELETE /conference/{conferenceId} call made from Prosody to reservation system when Prosody instance in your Jitsi setup goes down

Observations :

• Prosody clears all reservations it had stored in its memory upon being killed, which is a valid behaviour because of the fundamentals of how mod_reservartions.lua script functions
• Reservation system still thinks that all conferences that are active, are still available because it never got notified in any way about the recent state change against all such conferenceId that it holds

[anirbandas18]

Fixed this by implementing custom web services on the backend to listen for prosody pod lifecycle events via Kubernetes API