Kernel 4.0: ¿Live Patching? No para Fedora (al parecer)


Según me comentan vía Reddit enlazándome a este post no parece factible que Fedora Linux vaya a integrar las funcionalidades de Live Patching del Kernel 4.x.x en un futuro... Para empezar tanto los kernels disponibles en fedora 22 como en fedora rawhide actualmente vienen compilados con esta opción deshabilitada por defecto. Esta decisión se tomó más que nada por el simple hecho de que el Live Patching todavía se encuentra en un estado muy verde, donde el Kernel ya acepta parches en vivo tanto usando la metodología de KGraft como la de KPatch (los proyectos de RedHat y SUSE que se unieron para hacer esta funcionalidad del kernel posible); Pero aún no hay una manera única/unánime de manejar el live patching; Cabe destacar que existe un repositorio COPR llamado kernel-playground que contiene versiones del kernel compiladas con la función de live patching habilitada, pero de usar estos kernels te quedarás prácticamente de manera oficial sin soporte por parte de la comunidad upstream.

Por otro lado, asumiendo que llegue a haber un consenso/unificación en el método para aplicar el live patching en un futuro cercano, la probabilidad de que esta característica particular desembarque en Fedora es un tanto  baja por varias razones:

  • Fedora tiene un rolling kernel (serían muchísimos por mantener)
  • Fedora hace saltos mayores del kernel frecuentemente
  • El Live Patching sólo sirve para aplicar fixes menores actualmente

Los problemas reales aquí son la cantidad de live patches que se tendrían que mantener por release (tomando en cuenta el modelo de actualización del kernel que sigue fedora) y el hecho de que de momento las metodologías de live patching no permiten hacer saltos mayores de kernel (es decir, no podrías actualizar de manera rebootless de la versión 4.0 a la 4.1); sólo se pueden aplicar pequeños fixes de manera similar a lo que harías con las systemtap bandaids pero de manera más permanente.

SIN EMBARGO ni el autor del post que enlazo augurando poca probabilidad de integración ni yo descartaríamos la existencia de un kernel que se valga de esta funcionalidad para fedora (sobretodo teniendo en cuenta que ahora existe fedora server) dado que el código del live patching siempre puede mejorar y se puede hacer una sola rama del kernel que permita este tipo de parches sin tener que permitirlos en la rama "upstream". ¿Algo así como un "LTS Kernel/Tumbleweed Spin" para fedora server quizá? El tiempo lo dirá.

Ahora bien, A mi me parece que para empezar a ver por donde se moverá el asunto pasará un tiempo y los hechos son que por ejemplo cosas como el kernel 3.10 LTS de upstream jamás se lograron establecer en Fedora como algo fijo. actualmente el reino de los servidores se rige por el concepto de "ganado y no mascotas". La nube ha hecho bastante barato el deployment de clústers e instancias de failover donde si uno de tus nodos "se enferma" lo eliminas, picas un botón y vámonos! tienes otro corriendo que lo reemplaza al instante directo desde un snapshot, es lo mismo a la hora de las updates críticas, con tener algún mecanismo de failover a la mano, bien puedes actualizar y reiniciar un nodo en lo que otro se encarga de las requests/trabajos entrantes y listo... ¡Carajo! Con todo eso de las nubes administradas ya a casi nadie le importan los engranes de la situación: Cada día el datacenter privado desaparece más y más del mapa y aquí se engloba desde:

  • El geekstudio con con 1 solo servidor físico 
  • La empresa con un cluster de unos cuantos miles de dólares
  • Alguna mini-farm de una startup 


para dar lugar a las macrogranjas que rentan la infraestructura a todos por medio de interfaces web. Con lo fácil (y barato) que es tener montada una downtime strategy en la nube actualmente este tipo de features que suenan bien para alargar el uptime de servidores únicos parece que llegaron un poco tarde, porque quien tiene dinero, tiene el equipo para hacer failover sin problemas (macrogranjas) quien no tiene el equipo, consigue rentado muy barato para implementar una buena downtime strategy (usuarios que tienen acceso a VPS/Cloud) y finalmente los "pet projects" que podrían beneficiarse de esto (el servidor multimedia en tu sala) realmente no son de misión crítica y bien pueden tener downtime durante 10-15 seg para actualizar su kernel y reiniciar. Sin embargo, (como ya dije) la situación queda en veremos, y la moneda está en el aire...