Se suponía que GlusterFS estaba muerto, hasta que volvió a Proxmox 9

La función que desapareció y la gente que se negó a pasar página

Algunas eliminaciones parecen menos una limpieza que un portazo a toda una clase de usuarios. Proxmox 9 quitó GlusterFS como tipo de almacenamiento, y para quien todavía lo usaba eso fue más que una línea en un changelog. Fue un mensaje claro de que la plataforma ya no quiere invertir energía ahí. El camino oficial era bastante evidente: pasar página, usar Ceph u otra cosa y dejar de aferrarse a un stack de almacenamiento que el resto del ecosistema ya empezaba a tratar como muebles viejos en el sótano.

Aun así, las comunidades de código abierto no siempre aceptan el ánimo oficial. Un usuario creó un plugin de almacenamiento propio para recuperar GlusterFS en Proxmox 9, con parches extra para devolver piezas como pvesm scan y el soporte en la GUI. Es de esas cosas que hacen que la gente aplauda y haga una mueca a la vez. Por un lado, es justo el motivo por el que la gente adora este mundo: se recorta una función y alguien con suficiente irritación y habilidad dice: "Bueno, pues ya la vuelvo a poner yo". Por otro, plantea una pregunta incómoda que nadie puede esquivar para siempre: si una plataforma retiró el soporte porque la situación upstream es inestable, ¿recuperarlo resuelve el problema o solo gana tiempo?

Esa tensión recorrió toda la conversación. Algunos estaban agradecidos, otros eran escépticos y otros casi lloraban a GlusterFS como a un viejo amigo al que ya cuesta demasiado defender en público. El plugin fue la excusa, pero el hilo iba en realidad de lo que pasa cuando una tecnología de almacenamiento sigue funcionando para algunos, sigue despertando lealtad y sigue cubriendo un nicho, pero ya no encaja en la hoja de ruta, pensada primero para la empresa, del hipervisor que la rodea.

Eso es lo que escuece. GlusterFS no desapareció porque todos los usuarios lo odiaran. Desapareció porque la carga de soporte, el impulso upstream, los cambios en QEMU y las expectativas empresariales empezaron a apuntar en la dirección equivocada.

"Mantenido" carga con mucho peso aquí

La discusión más afilada giró en torno a una palabra: mantenido. Parece sencilla hasta que un sistema de almacenamiento depende de ella. Un bando señaló que GlusterFS ha llegado al final de su vida útil, o al menos que ya no se mantiene de ninguna forma que consideraran significativa. La advertencia fue directa: lo quitaron de Proxmox por algo, y la gente debería tener cuidado antes de construir nada importante sobre un plugin resucitado. Alguien vino a decir que un puñado de personas manteniendo el código a duras penas después de que desaparezca el gran respaldo corporativo es algo distinto de un proyecto sano al que se pueda dar soporte.

Es una visión dura, pero no irracional. Las plataformas empresariales necesitan dependencias aburridas, es decir, proyectos con un upstream activo, correcciones predecibles, un camino claro de versiones y el uso suficiente para justificar el esfuerzo de soporte. Un plugin de almacenamiento es más que una opción de menú. Toca los discos de las VM, las migraciones, las copias de seguridad, los escaneos, el aprovisionamiento y todos esos horribles casos límite que solo aparecen cuando el cliente ya está enfadado. Visto así, que Proxmox recortara GlusterFS fue gestión de riesgos más que una traición.

El otro lado respondió. El creador sostuvo que GlusterFS sigue mantenido, solo que despacio, sobre todo desde que Red Hat se apartó. Y, lo que es más importante, argumentó que la eliminación en Proxmox fue un error porque el driver de bloque de QEMU era solo una parte de lo que hacía el plugin de almacenamiento. Aunque QEMU haya retirado su driver nativo de Gluster, las VM pueden seguir ejecutándose sobre GlusterFS a través de FUSE, más o menos con el mismo esquema que el almacenamiento de tipo directorio. Para los usuarios que ya han invertido en Gluster, eso importa. No pedían a Proxmox que mantuviera un fork del mundo para siempre. Querían que la integración de almacenamiento existente siguiera siendo útil allí donde todavía podía serlo.

Así que el desacuerdo se reducía más a la confianza que a si el código existe. ¿Está un proyecto "mantenido" si unas pocas personas siguen arreglando lo que se rompe? ¿Está "muerto" si los grandes fabricantes han puesto su atención en otra parte pero los usuarios todavía pueden ejecutarlo? ¿Es aceptable un mantenimiento lento en un homelab pero no en una empresa? La respuesta depende de quién tenga que coger el teléfono cuando algo se rompa, y por eso el mismo plugin puede parecer heroico a una persona y temerario a otra.

GlusterFS vive ahora en una especie de purgatorio del código abierto: no está lo bastante muerto para desaparecer ni lo bastante vivo para inspirar confianza. Los usuarios fieles pueden mantenerlo en marcha, pero cada actualización es como comprobar si el suelo sigue ahí.

El argumento empresarial contra la nostalgia

El argumento empresarial se expuso con claridad. Proxmox es una plataforma pensada primero para la empresa, aunque tenga un enorme público no empresarial gracias a sus raíces de código abierto, así que el proyecto no puede mantener viva cada función solo porque a una parte de los usuarios todavía le guste. Si QEMU upstream retira un comportamiento, si el ecosistema de Gluster ya no parece sano y si los tickets de soporte empresarial no muestran demanda suficiente, mantener GlusterFS dentro de la plataforma oficial se vuelve difícil de justificar.

No resulta satisfactorio emocionalmente, pero así sobreviven los productos. Dar soporte al almacenamiento no se parece en nada a dar soporte a una opción de tema olvidada, porque los bugs de almacenamiento son bugs que acaban con carreras. Un plugin poco fiable puede destruir la confianza más deprisa que casi cualquier otra cosa en un stack de virtualización. Los usuarios empresariales quieren funciones que el fabricante pueda respaldar sin murmurar algo sobre parches, capas FUSE y "bueno, técnicamente sigue funcionando". Cuando vendes soporte, "técnicamente" no basta.

Un comentarista señaló la postura declarada de la propia Proxmox: las evaluaciones del soporte empresarial no mostraban suficiente uso de GlusterFS para justificar el esfuerzo. Puede sonar frío, pero explica mucho. Los proyectos de software toman decisiones en función de dónde están los usuarios, hacia dónde va upstream y dónde es probable que se disparen los costes de soporte. En esas cuentas, GlusterFS se convirtió en una mala apuesta. Ceph, el almacenamiento de objetos y las prioridades cercanas a OpenStack se impusieron, y GlusterFS pasó a ser la respuesta de ayer.

También hubo reproches para Red Hat e IBM, con el tono amargo de quien recuerda cuando GlusterFS parecía más central. Una persona dijo que IBM dejó a los usuarios a la intemperie cuando dejó de apoyarlo. Otra dijo que Red Hat simplemente había cambiado de rumbo hacia el almacenamiento de objetos y OpenStack. Se mire como se mire, la sensación es la misma: una tecnología que la gente usaba y en la que confiaba perdió el impulso institucional, y los proyectos que dependían de ella reaccionaron en consecuencia.

Eso es lo que más odian los usuarios. Algo puede seguir siendo útil y aun así ser abandonado por las empresas que en su día le dieron legitimidad. Quienes lo ejecutan se quedan con scripts, plugins, hilos de foro y una elección: migrar antes de que el terreno vuelva a moverse o seguir parcheando porque el montaje actual todavía cumple.

Por qué la gente todavía echa de menos GlusterFS

El cariño por GlusterFS no era imaginario. Una persona dijo que lo prefería a Ceph porque Ceph tiene más sobrecarga, mientras que a GlusterFS podías apuntarlo a casi cualquier cosa y simplemente decía "de acuerdo". Esa frase resume su atractivo. GlusterFS resultaba accesible. No exigía el clúster cuidadosamente dimensionado, la red rápida, la planificación de discos y la disciplina operativa que Ceph suele pedir. Para montajes pequeños, laboratorios, hardware raro y gente que quería almacenamiento distribuido sin levantar una catedral entera a su alrededor, GlusterFS tenía su encanto.

Ceph puede ser brillante, pero no admite improvisaciones. Quiere un diseño de verdad, con suficientes nodos, discos, red y conocimientos. GlusterFS, al menos en su versión más amable, era más indulgente. La gente sigue recurriendo a él porque hacía posibles ciertos montajes desordenados sin obligarles a convertirse en arquitectos de almacenamiento de la noche a la mañana, aunque no gane todos los benchmarks ni marque todas las casillas empresariales modernas.

La nostalgia venía con cicatrices. Alguien que en su día adoraba GlusterFS dijo que ese amor terminó con el fallo de un nodo, porque el problema eran las reconstrucciones. Otro usuario contó que lo probó con una red dedicada de 10Gbps para la comunicación entre nodos y aun así el rendimiento quedó por debajo de lo esperado, y que además lo dejó porque no tenía snapshots nativos. Son quejas serias. El rendimiento, el comportamiento en las reconstrucciones y los snapshots no son funciones decorativas cuando hay almacenamiento de VM de por medio; marcan la diferencia entre "qué ingenioso" y "esto me va a arruinar el fin de semana".

Por eso la conversación no se convirtió en una simple celebración. GlusterFS tiene fans, pero hasta los fans saben dónde están los moratones. El plugin devuelve un camino a quien todavía lo quiere, pero no reescribe la historia, no hace agradables las reconstrucciones ni añade por arte de magia la confianza operativa que desapareció con el soporte de los grandes fabricantes. Da control a los usuarios, lo cual es muy potente, pero el control por sí solo no lo hace seguro.

Aun así, hay algo con lo que es fácil identificarse en la gente que se niega a abandonar una herramienta porque ya no está en el carril bendecido. La infraestructura está llena de estas lealtades. La gente sigue usando lo que entiende, lo que cabe en su presupuesto, lo que sobrevivió a desastres anteriores o lo que simplemente funciona bastante bien en un hardware que Ceph miraría con desprecio. A veces eso es mala ingeniería y a veces es sabiduría práctica. Normalmente es las dos cosas.

Un plugin puede revivir una función, pero no un ecosistema

El plugin es útil e impresionante, pero no es una máquina del tiempo. Puede recuperar el soporte de almacenamiento GlusterFS dentro de Proxmox 9, parchear los escaneos y devolver el comportamiento de la GUI. Puede facilitar la vida a quien ya ha actualizado, o quiere hacerlo, sin arrancar antes su stack de almacenamiento. Para los usuarios de la comunidad es un regalo de verdad, porque convierte el "no puedes" en "puedes, con salvedades", y en el mundo del código abierto eso importa.

Pero las salvedades son toda la historia. En cuanto el soporte sale de la plataforma principal, los usuarios pasan a formar parte del modelo de soporte, les guste o no. Cada actualización de Proxmox, cada cambio en QEMU, cada rareza de GlusterFS, cada comportamiento de FUSE y cada caso límite extraño del almacenamiento se convierte en algo que vigilar. El plugin puede ser sólido hoy y dar guerra mañana sin que sea culpa de quien lo escribió. Ese es el impuesto que pagas por recuperar una función que la plataforma decidió dejar atrás.

En realidad hay tres posturas. La primera dice que Proxmox acertó: GlusterFS está demasiado débil upstream, tiene muy poca demanda empresarial y es demasiado arriesgado para seguir cargando con él oficialmente. La segunda dice que la eliminación fue demasiado brusca, ya que GlusterFS sobre FUSE sigue funcionando sin el driver de QEMU y el plugin de almacenamiento hace más que un único trabajo acotado de driver de bloque. La tercera dice que todo esto pierde de vista lo práctico: hay gente que ya tiene GlusterFS, ya conoce sus contrapartidas y necesita un puente, no un sermón.

Esa tercera postura puede que sea la más honesta. Un plugin como este es más un bote salvavidas o una válvula de escape que una revolución: un usuario habilidoso que dice "sé que esto no es el futuro, pero sigue siendo mi presente".

El peligro está en fingir que el bote salvavidas es un crucero. Ejecutar GlusterFS en Proxmox 9 mediante parches de la comunidad puede estar bien para laboratorios, migraciones, montajes de nicho y gente que entiende del todo el radio de impacto. Es más difícil de defender para despliegues empresariales nuevos sin un motivo muy concreto y un plan de soporte muy sensato. El plugin devuelve la posibilidad de elegir, pero no devuelve la confianza oficial.

El episodio escuece porque muestra la desordenada vida después de la muerte del software útil. Un proyecto se apaga, un fabricante pasa a otra cosa, una plataforma retira el soporte, los usuarios protestan y alguien escribe código. La función vuelve de otra forma, con una etiqueta, tanto si alguien la imprime como si no: resucitada por la comunidad, procede con los ojos abiertos.

GlusterFS no está del todo muerto, y tampoco está vivo como antes. En algún punto de ese terreno intermedio e incómodo, un plugin de Proxmox hecho por la comunidad está haciendo lo que el código abierto siempre ha hecho mejor: negarse a que el final oficial sea el único final.