Tengo un sistema de ejecución prolongada que nunca había tenido problemas antes. Siempre actualizo mediante una reconstrucción completa, nunca usando la actualización integrada.
Recientemente ejecuté un apt-get upgrade, actualicé Docker a la versión 19.03.5 e intenté una reconstrucción, pero ahora está roto. El sistema es Ubuntu 16.04.6.
@j.jaffeux ¿Debería Discourse.redis ser retrocompatibilizado en stable y beta? Supongo que eso sería más fácil que agregar código para compatibilidad hacia atrás en múltiples plugins.
Estoy bastante seguro de que los últimos cambios rompen docker_manager, ya que se actualiza antes que Discourse y, por lo tanto, no encuentra Discourse.redis.
Resumen breve: tests-passed funcionó, tuve un tiempo de inactividad de 1 día.
Versión más larga: Creo que este es uno de los programas de código abierto de mayor calidad escritos en internet hoy en día, con un modelo de negocio sólido y un gran equipo. ¿Cómo es posible que el mecanismo de actualización esté tan roto?
La función de actualización dentro de la aplicación me causó tantos tiempos de inactividad que decidí no usarla en absoluto, y en su lugar siempre realizar una reconstrucción.
Pero como pueden ver en este hilo, en las últimas 2 de 2 ocasiones, la reconstrucción también dejó la aplicación muy rota, algo que no podía arreglar por mí mismo, salvo acudir a “tests-passed” siguiendo las recomendaciones aquí.
¿Por qué el mecanismo de actualización está tan roto en un software tan bien escrito? ¿Por qué tengo sitios de WordPress de más de 5 años funcionando sin problemas con su mecanismo de actualización integrado?
¿Cuál es el punto de tener versiones en Discourse si literalmente no hay forma de usarlas? Una reconstrucción siempre es desde una rama de git y las versiones no tienen nada que ver con git.
Para mí, una versión sería o bien una etiqueta de git o un archivo zip. ¿Por qué no puedo simplemente usar reconstrucción con 2.3.x, como podría hacerlo con cualquier gestor de paquetes moderno hoy en día?
Resulta que tests-passed es la versión que discourse.org despliega en sus servidores, y está mejor probada y es más fiable que stable. Si te mantienes en tests-passed, tendrás menos problemas. Si deseas ejecutar stable, debes tener en cuenta que requerirá más trabajo que ejecutar tests-passed, como poner en marcha un servidor de staging para probar las actualizaciones antes de aplicarlas en producción.
Solo quiero algo que sea estable y confiable, y basado en
tests-passed es lo que discourse.org despliega en sus servidores y está mejor probado y es más confiable que stable.
Me quedaré con esto. Dos cosas siguen siendo muy extrañas:
¿Por qué se llama test-passed y no stable, si realmente es estable? “stable” podría renombrarse a algo como “legacy”.
El sistema de lanzamientos aún no tiene sentido. Si estamos construyendo desde una rama de Git, ¿cuál es el propósito de hacer lanzamientos en absoluto? Me encantaría poder quedarme con la versión 2.3.x hasta que la 2.4.x madure, por ejemplo, y creo que con el modelo de Discourse esto no es posible en absoluto.
Con todo respeto, pero no estoy de acuerdo con esto. Stable es muy fiable y, bueno, estable. Rubygems actualizó una dependencia que rompió tantotests-passedcomostable, y resolverlo fue simplemente cuestión de hacer un backport de una solución.
Por cierto, esto se podría haber evitado fijando rubygems a una versión específica en el comando gem update. gem update --system 3.0.6 habría sido seguro.
El hecho de que stable estuviera roto por más tiempo que tests-passed es solo una coincidencia y, hasta donde recuerdo, una primera vez.
Hemos estado haciendo esto (mantener stable como predeterminado) durante más de seis años con cientos de instancias de Discourse sin problemas significativos.
Solo en este hilo hay múltiples ocasiones en las que la versión estable dejó de funcionar correctamente, definitivamente no es la primera vez. Si las instancias comerciales de discourse.org han superado las pruebas, me quedaré con esa.
Hemos estado haciendo esto (mantener la versión estable como predeterminada) durante más de seis años con cientos de instancias de Discourse sin problemas significativos.
Mantenerse en la versión estable y mantenerse en la 2.3.x son cosas muy diferentes. Por ejemplo, la versión estable no te permite quedarte en la 2.3.x hasta que la 2.4.x madure lo suficiente. Por ejemplo, con todo lo que está en producción, prefiero no actualizar hasta que salga la x.x.3 o la x.x.4. Creo que hoy en día esto no es posible.
Sé que es cierto, pero tú no eres el administrador promedio de Discourse. Me has salvado un montón de veces y, por norma general, leo todo lo que dices dos veces para asegurarme de recordarlo, pero sigo pensando que para la mayoría de las personas normales lo más seguro es quedarse con tests-passed.
Puedes usar un ID de commit de git en lugar de una etiqueta.
Pero incluso si lo hago, eso no me salvará en una situación donde la versión estable esté rota, ¿verdad? En ambos casos, el problema fue la falta de un backport, y eso también faltaría en cualquier ID de commit de git, creo.
Por lo tanto, no existe algo así como una “versión” de Discourse donde descargues un archivo zip al estilo de WordPress o uses un gestor de paquetes como yarn/pip/gem, simplemente porque Discourse no se “lanza”, sino que se “reconstruye” siempre utilizando versiones en vivo de paquetes externos.
Me has salvado un montón de veces y, por norma general, leo todo lo que dices dos veces para asegurarme de recordarlo, pero sigo pensando que para la mayoría de las personas normales lo más seguro es quedarse con tests-passed.