Squid ganó 42 días y Tentacle perdió 170: el fin de soporte de Ceph lo movió un commit

El 5 de agosto, a las 14:48 UTC, un commit en la documentación de Ceph movió las dos fechas que ordenan el calendario de cualquiera que tenga almacenamiento distribuido en producción. Squid pasó del 19 de septiembre al 31 de octubre: 42 días más. Tentacle pasó del 18 de noviembre de 2027 al 1 de junio de 2027: 170 días menos. La prórroga de Squid se ve en cuanto miras el gráfico de la documentación. El recorte a Tentacle no lo hemos visto comentado en ninguna parte. Y es el que importa, porque Tentacle es la versión a la que estás migrando.

Operamos Proxmox VE con almacenamiento Ceph en producción, repartido en varios centros de datos, así que estas dos fechas no son trivia: son ventanas de mantenimiento con nombre de persona y hora de inicio. Hoy, 8 de septiembre, quedan 53 días para el 31 de octubre. Este artículo va de dónde vive esa fecha, quién la escribe y por qué planificar contra ella es una mala idea aunque la fecha sea correcta.

Las dos fechas y el commit que las movió

El diagrama de barras que sale en docs.ceph.com/en/latest/releases/ —el que todo el mundo mira para saber hasta cuándo está soportada su versión— no es una tabla escrita a mano en una página web. Se genera a partir de un fichero YAML del repositorio de Ceph: doc/releases/releases.yml. Ese fichero tiene una entrada por serie estable, y dentro un campo que decide el color de tu otoño: target_eol.

El commit c1e13dbc, del 5 de agosto de 2026 a las 14:48 UTC, firmado por Patrick Donnelly, cambió cuatro de esos campos. En Tentacle, target_eol pasó de 2027-11-18 a 2027-06-01. En Squid, de 2026-09-19 a 2026-10-31. Y en Reef corrigió dos fechas de marzo. Eso es todo: un fichero de texto, cuatro líneas, ningún anuncio, ninguna nota de versión.

Merece la pena detenerse en el nombre del campo antes de seguir. No se llama eol. Se llama target_eol: fin de vida objetivo. Al lado, en la entrada de Reef, hay otro campo distinto, actual_eol. El proyecto distingue explícitamente entre la fecha que se pretende y la que acaba siendo. La página que renderiza el gráfico lo dice también, con esas palabras: «End of life (estimated)». La fecha contra la que planifica media industria viene etiquetada como estimación por quien la publica.

El mensaje del commit dice más que el diff

El cuerpo del mensaje son cuatro frases y explican el mecanismo entero: «Based on my own estimates. Squid will have one more bug fix cycle after v19.2.6. Vampire will release in March. We will likely have 1 or 2 more bug fix cycles before tying it off.»

Léelo otra vez, porque no es una fecha: es una cuenta de publicaciones pendientes. El fin de soporte de tu almacenamiento no se calcula con un calendario, se calcula contando cuántas versiones de corrección le quedan a la serie y cuándo se espera la siguiente release grande. Si esos dos números se mueven —y se mueven, porque dependen de cuánto trabajo entre y de cuándo esté listo—, la fecha se mueve detrás. Es honesto y es razonable. Lo que no es razonable es tratar el resultado como una garantía contractual, que es exactamente lo que hace la mayoría de los planes de actualización que hemos leído.

Una nota sobre «Vampire will release in March»: Ceph nombra sus series por orden alfabético, así que después de Tentacle (T) viene Umbrella (U) y luego Vampire (V), que en el proceso de release del propio proyecto figura como la 22. Una serie estable muere poco después de que salga la que va dos por delante, así que ese «marzo» encajaría con el 1 de junio de 2027 de Tentacle. Decimos «encajaría» a propósito: el commit no dice el año, y para que Vampire salga en marzo de 2027 tendría que haber salido antes Umbrella, de la que a día de hoy no hay ni una versión 21.x en el fichero. La cadena cuadra, pero es lectura nuestra, no un dato del proyecto.

765 días contra 560

La documentación de Ceph explica cuánto debería durar una serie estable: «The lifetime of a stable release series is calculated to be approximately 24 months (i.e., two 12 month release cycles) after the month of the first release». Y añade, dos frases más abajo, el matiz que casi nadie cita: «The lifetime of a release may vary because it depends on how quickly the stable releases are published».

Ahora la aritmética, que la pinta la propia página en las barras del gráfico. Squid salió el 26 de septiembre de 2024 y muere el 31 de octubre de 2026: 765 días, veinticinco meses. Tentacle salió el 18 de noviembre de 2025 y muere el 1 de junio de 2027: 560 días, dieciocho meses y medio. La versión nueva vive un 27% menos que la que sustituye, y 170 días menos de lo que su propio proyecto describe como duración normal. Y ojo, que ese 170 y el del titular son el mismo número, no dos hallazgos: la fecha antigua de Tentacle, 18 de noviembre de 2027, eran exactamente 730 días desde su publicación. Veinticuatro meses clavados, la política al milímetro. Lo que hizo el commit fue dejar de aplicarla.

Y de ahí sale el número que de verdad cambia un plan. Si apuras Squid hasta el último día y haces la ventana el 31 de octubre, entras en Tentacle con 213 días de soporte por delante. Siete meses. La actualización que ibas a vender internamente como «esto nos deja tranquilos dos años» te deja tranquilo hasta después de Semana Santa, y la siguiente ventana ya la tienes que empezar a negociar mientras cierras esta. Eso no invalida la migración —hay que hacerla igual—, pero cambia por completo la conversación con dirección sobre qué se está comprando.

Lo que Proxmox dijo a sus usuarios en enero

El 9 de enero de 2026, en el hilo del foro donde se anunció Tentacle como vista previa, un miembro del equipo de Proxmox lo dejó escrito así: «The current default Ceph 19.2 Squid will stay supported until September 2026 for the time being». Ese «for the time being» —«por ahora»— estaba haciendo mucho más trabajo del que parecía. El hilo sigue ahí y sigue diciendo septiembre; la fecha buena está en un YAML que ese hilo no enlaza.

Nosotros tampoco salimos indemnes de esto, y lo decimos con el enlace puesto: el post que publicamos el 31 de julio lleva el 19 de septiembre en el título. Esa fecha ya no es la buena. En el artículo del 2 de septiembre sobre la ventana de actualización ya escribimos 31 de octubre, pero sin explicar por qué había cambiado, porque entonces no lo sabíamos. Ahora sí: cambió en un commit del 5 de agosto y aquí está el enlace.

Reef enseña qué pasa cuando la lista y la realidad no coinciden

En el mismo fichero, la entrada de Reef tiene hoy un campo que las otras dos no tienen: actual_eol, con fecha 2025-03-20. Lo interesante no es la fecha, es cuándo apareció. Ese campo no existía: lo añadió el commit a3eea0c9 el 22 de julio de 2026 —el mismo que sacó a Reef de la lista de versiones activas— con un valor retroactivo de dieciséis meses atrás. Dos semanas después, el commit del 5 de agosto le corrigió el día.

Traducido: el proyecto no dijo nunca, mientras estaba pasando, que Reef estuviera muerta. Lo escribió después. Y mientras tanto, la lista que empieza diciendo «The following Ceph releases are actively maintained and receive periodic backports and security fixes» siguió incluyendo a Reef hasta ese 22 de julio. La fecha de defunción y el certificado se firmaron el mismo día, con dieciséis meses de diferencia entre una y otro.

Ahora, cuánto tiempo dijo de más depende de qué fecha te creas, y aquí toca ser honestos con lo que no sabemos. La lectura larga la apoya Proxmox, que en enero de 2026 escribía que Reef «has been end of life (EOL) for a while, albeit there is an effort underway to get one last post-EOL update out». La corta la apoya el propio fichero, que registra cuatro publicaciones posteriores a esa fecha de defunción —18.2.5, 18.2.6, 18.2.7 y 18.2.8—; y que los campos de Reef acabaran cuadrando con el día exacto de 18.2.8 con un año redondo de diferencia hace bastante verosímil que ese 2025 sea un lapsus y que la respuesta buena sean cuatro meses, no dieciséis. Nos quedamos con la lectura corta, que es la que menos favorece a nuestro propio argumento. Y el argumento aguanta igual: el campo que decide si tu almacenamiento recibe parches de seguridad se escribe a mano, a veces con meses de retraso, y no avisa a nadie cuando cambia.

Qué compra exactamente estar en la lista

El 19 de agosto, Ceph publicó a la vez 20.2.4 y 19.2.6 para cerrar cuatro CVE: un bypass de autenticación en CephX por mal uso de AES-CBC (CVE-2025-30156), un fallo de verificación de firma en los tokens de sesión STS de RGW (CVE-2026-39944), una autorización indebida en el manejador de suscripciones del monitor (CVE-2026-50152) y otra firma SigV4 mal verificada en RGW (CVE-2026-54330). El aviso pedía subir «to one of these releases as soon as possible». Una de esas dos. Las dos que estaban en la lista.

Eso es lo que se cae el día que tu serie sale de la lista, y conviene decirlo sin adornos porque no es lo que la gente teme: no pierdes funcionalidad ni te deja de arrancar nada. Lo que pierdes es el backport. El día 1 después del fin de soporte tu clúster funciona exactamente igual que el día anterior; la diferencia aparece la primera vez que sale un CVE de monitor o de RGW y tú no estás en la frase del aviso. Lo desarrollamos con más detalle en el análisis de esos cuatro CVE, donde además hay uno que el paquete no cierra por sí solo.

Los 42 días de prórroga son la peor noticia del commit

La reacción natural al leer el diff es quedarse con lo bueno: seis semanas más de Squid, la ventana de octubre respira. Nos parece justo al revés, y esta es la opinión, no el dato. Un margen que aparece por sorpresa puede desaparecer por sorpresa, y el mismo commit lo demuestra dos líneas más arriba, quitándole 170 días a Tentacle sin que a nadie se le ocurra que eso también podía pasar.

Dicho de la forma más corta que se nos ocurre: si tu plan de actualización cabía dentro de esos 42 días, tu plan no era un plan. Era una fecha con suerte.

Planificar contra ciclos, no contra fechas

La pregunta útil no es «¿cuándo caduca?». Es «¿cuántas publicaciones de corrección le quedan?», y el commit la contesta mejor que cualquier calendario: una más para Squid después de 19.2.6. Con esa respuesta encima de la mesa, la ventana la fijas contra una fecha tuya —firmada por alguien y metida en el calendario de este mes, no en el de octubre— y el target_eol vuelve a ser lo que es: la estimación de un tercero sobre su propio trabajo.

Y si quieres enterarte el día que vuelva a moverse, vigila el fichero, no la página. GitHub publica un feed Atom por ruta, y ese fichero tiene el suyo: https://github.com/ceph/ceph/commits/main/doc/releases/releases.yml.atom. Es el sitio más práctico para verlo el mismo día que ocurre, porque no hay ningún anuncio que esperar: el anuncio es el commit. Cuesta dos minutos meterlo en el lector que ya usas o en el canal de guardia, y es lo más cerca que vas a estar de que estas fechas te avisen a ti en vez de al revés.

Dentro del clúster, la comprobación que más veces hemos encontrado pendiente es la de qué versión has declarado, que no es la misma pregunta que qué versión tienes instalada: un clúster puede llevar meses con todos los binarios en 20.2 y la declaración todavía en Squid. Se lee con ceph osd dump | grep require_osd_release y lo desarrollamos en el artículo sobre la ventana de actualización. Queda luego la decisión de fondo: con 560 días de vida útil, para algunos clústeres la respuesta honesta es que Tentacle es una parada y no una casa, y eso se planifica distinto, con la ventana siguiente ya dibujada. Correr una versión fuera de soporte, además, es de las cosas que un auditor encuentra rápido: entra directo en el expediente de cumplimiento y continuidad.

Nada de esto cuesta dinero ni lleva más de una tarde. Lo único que requiere es que alguien tenga asignado mirarlo, que es la parte que en la mayoría de las empresas no está asignada a nadie: no porque no se sepa hacer, sino porque no aparece en ningún ticket hasta que ya es tarde. Eso también es mantenimiento planificado, aunque no lo parezca.

Nota de fuentes

El commit que mueve las fechas es c1e13dbc en github.com/ceph/ceph, del 5 de agosto de 2026, sobre doc/releases/releases.yml; el diff y el mensaje están citados literalmente. La salida de Reef de la lista de versiones activas y la aparición retroactiva del campo actual_eol son el commit a3eea0c9, del 22 de julio de 2026; las cuatro publicaciones posteriores a esa fecha (18.2.5, 18.2.6, 18.2.7 y 18.2.8) están en el mismo YAML. La política de duración de las series y las frases sobre mantenimiento activo salen de doc/releases/general.rst y doc/releases/index.rst, publicadas en docs.ceph.com/en/latest/releases/, de donde también salen las barras de 765 y 560 días y la etiqueta «End of life (estimated)». Las fechas de publicación de 19.2.0, 20.2.0, 19.2.6, 20.2.4 y 18.2.8 son las del mismo fichero. Los cuatro CVE y la frase de recomendación son del aviso combinado de Ceph del 19 de agosto de 2026. Las citas de Proxmox son del hilo del foro del 9 de enero de 2026 en el que se anunció Tentacle como vista previa. Los cálculos de 42, 170, 765, 560, 213 y 53 días son aritmética nuestra sobre esas fechas. La lectura de que «March» se refiere a marzo de 2027 es interpretación nuestra y está marcada como tal en el texto.