Alta disponbilidad

[fguinez]

De momento no he encontrado una forma de actualizar la lista de grupos que reciben mensajes sin pausar momentáneamente el funcionamiento de matterbridge.

• Actualmente funciona corriendo matterbridge con un timeout de 1 hora, para luego general una lista actualizada de los grupos y volver a correr matterbridge con el mismo timeout. Esto genera que, cada 1 hora, el servicio se ve interrumpido por unos segundos.
• Posibles soluciones:
  1. Descubrir cómo actualizar la lista de grupos en ejecución para no interrumpir el servicio (no tengo la menor idea).
  2. Aumentar el timeout. Esto disminuiría la cantidad de interrupciones, pero tardaría más en integrar grupos nuevos a la lista.
  3. Ajustar interrupción a una hora conocida. Esto se puede realizar con datetime, calculando en cada iteración el timeout necesario para que la interrupción ocurra a una hora conocida. Por ejemplo, planificar una interrupción al comienzo de las horas impares (3:00, 5:00, 7:00, etc.).

Hasta ahora, lo que me parece más realizable es implementar una mezcla de las soluciones (ii) y (iii), definiendo que la lista se actualice en un horario predefinido con reducidad opciones. Por ejemplo: 00:00, 6:00, 12:00, 18:00

[fguinez]

@ngeorger tal vez esto te sea de ayuda

[agucova]

No sé cómo estamos en Go, pero qué tan inviable es forkear matterbridge para este propósito?

Mi tema es que implementar "hot reload" suena bastante involucrado.

[fguinez]

Al menos yo se lo básico nomás de Go, no me siento capacitado para ese fork. Si a eso le sumamos que la idea es que esto empiece a funcionar ahora ya, me quedaría con la opción de minimizar las interrupciones (y conocer cuando ocurren) nomás.

Ahora ideal si aparece alguien con la motiviación de forkear matterbridge y solucionar el problema, le daría estrellita en todos sus repos y le pediría una clase de cómo lo hizo jajaja

[ngeorger]

Creo que la solución sería combinar infra y código:

• Código detecte cambio de versionado de archivo objetivo, al cual se le da high availability, en el sentido de réplicas y multizonas. Ésto puede hacersae fácil, de dos formnas:
  • Simple, rapida y bonita: Bucket en GCP con téplicas y versionado con terraform para control de cambios descentralizado.
  • Con la solución anterior, el bucket por si solo puede emitir unna notificación y ésta notificación le indica a un tópico con suscripcion abierta de que el archivo dcambio y que lo vaya a buscar

Es lo que se me ocurre rapico ahora.

[ngeorger]

Creo que la solución sería combinar infra y código:

• Código detecte cambio de versionado de archivo objetivo, al cual se le da high availability, en el sentido de réplicas y multizonas. Ésto puede hacersae fácil, de dos formnas:

  • Simple, rapida y bonita: Bucket en GCP con téplicas y versionado con terraform para control de cambios descentralizado.
  • Con la solución anterior, el bucket por si solo puede emitir unna notificación y ésta notificación le indica a un tópico con suscripcion abierta de que el archivo dcambio y que lo vaya a buscar

Es lo que se me ocurre rapico ahora.

Referencia: https://cloud.google.com/storage/docs/gsutil/commands/notification Codigo referencial en go, a vuelo de pájaro: https://pkg.go.dev/google.golang.org/cloud/storage#hdr-Creating_a_Client

[fguinez]

De momento, implementé la mezcla de las soluciones (ii) y (iii) en el Pull Request #2, donde se realiza la integración de grupos nuevos 1 vez al día a las 4AM.

No cerraré la issue todavía por si eventualmente alguien logra realizar la solución (i).