PTG (Project Team Gathering) es un evento donde los equipos de desarrollo se reúnen para discutir las tareas, estados y planes actuales. PTG surgió de la cumbre de OpenStack convencional hace unos años.
PTG se llevó a cabo por primera vez en línea a través de Zoom y Jitsi Meet. Sin embargo, la combinación de imagen y sonido en la reunión hizo que este cambio fuera completamente imperceptible, especialmente en el contexto de las ahora familiares reuniones del equipo de IRC.
Las sesiones de Neutron de tres horas se desarrollaron de martes a viernes. Las actas de la reunión principal se publican en OpenStack Etherpad y en la lista de correo de OpenStack. La agenda del evento se formó en base a las propuestas de los desarrolladores de Neutron, y el calendario de reuniones fue preparado por su presidente, PTL (Project Team Lead) del equipo Neutron Slawek Kaplonski.
En este artículo hablaré sobre 3 temas que creo que merecen atención y requieren una pequeña explicación.
OVN
Se habló mucho sobre OVN en este PTG, lo cual no es sorprendente ya que la mayoría de los miembros del equipo principal representan a RedHat, el principal contribuyente de OVN.
¿Qué es OVN?
- Virtualización de red de código abierto L2 / L3 para Open vSwitch (OVS):
- Interruptores lógicos
- Enrutadores lógicos IPv4 e IPv6
- ACL L2 / L3 / L4 (grupos de seguridad)
- Superposiciones de múltiples túneles (Geneve, STT y VXLAN)
- Equilibradores de carga lógicos
- Pasarelas L2 lógico-físicas basadas en TOR
- Pasarelas L2 / L3 lógico-físicas basadas en software
- Funciona en las mismas plataformas que OVS:
- Linux
- Contenedores
- DPDK
- Integración con:
- OpenStack Neutron
- Enjambre de Docker
- Kubernetes
Arquitectura OVN
“OVN en 75 palabras.
La Red Virtual Abierta es operada por el proyecto OVS y desarrollada por el equipo original de OVS. Esta decisión es un intento de rediseñar el plano de control ML2 / OVS basado en años de experiencia. Está diseñado para su uso con OpenStack y Kubernetes. OVN se basa en una nueva arquitectura que ha abandonado el concepto de agentes Python que interactúan con el servicio API de Neutron a través de RabbitMQ en favor de los demonios C que se comunican a través de OpenFlow y OVSDB ". - Slawek Kaplonsky, Neutron PTL.
Inicialmente, el controlador Neutron OVN se desarrolló como un proyecto separado en el estadio Neutron - networking-ovn, y en el lanzamiento Ussuri se incluyó en el repositorio principal de Neutron.
Así, esta solución elimina el problema principal de ML2 / OVS - RabbitMQ, que es un plus indudable, y en general “el objetivo del diseño de OVN es tener una implementación de calidad de producción que pueda operar a una escala significativa”. Sin embargo, ¿OVN admite la funcionalidad disponible cuando se usa ML2 / OVS? Parece que esto no es del todo cierto, que se convirtió en uno de los temas de discusión sobre el PTG. Como resultado, se destacaron varias lagunas (una lista completa está disponible en la página del proyecto). En primer lugar, los desarrolladores notaron la ausencia o el soporte incompleto para redes enrutadas, algunas características de QoS, BGP y zonas de disponibilidad. Si bien el equipo de OVN está dispuesto a hacer todo lo anterior, durante la reunión admitieron que antes no había sido una prioridad para ellos, ya que los intereses internos eran más importantes. Además, el desarrollo de ML2 / OVS, por supuesto,no se detiene, lo que significa que pueden aparecer nuevos espacios.
Sin embargo, en mi opinión, el principal problema de OVN es que todavía no se utiliza mucho y no se ha probado en grandes instalaciones. Además, hay algunas preguntas sobre la alta disponibilidad:
- Uno de los componentes principales, ovn-northd, actualmente solo admite el modo HA activo / pasivo, activo / activo solo está planeado por ahora
- Otro componente central, ovsdb-server, también solo admite el modo activo / pasivo
Es posible que el último punto esté desactualizado, ya que se agregó soporte para el clúster ovsdb (basado en el algoritmo Raft) desde OVS 2.9, pero no está claro si se probó con OVN y OpenStack. Por ejemplo, el ticket asociado en openstack-ansible aún no se ha cerrado.
También es motivo de preocupación que OVN utilice túneles Geneve en lugar de VxLAN, lo que afecta la configuración de MTU (los encabezados de Geneve son más grandes que las VxLAN) y el soporte para procesamiento de túnel acelerado por hardware.
Sea como fuere, el proyecto está ganando impulso rápidamente y parece que en un par de lanzamientos OVN debería convertirse en un complemento básico de Neutron. Además, durante PTG, los desarrolladores del equipo central acordaron hacer de OVN el complemento predeterminado para DevStack.
A dónde conducirán estos cambios:
- OpenStack Neutron CI,
- ML2/OVS ( )
- Neutron CI , ML2/Linuxbridge ML2/OVS – ,
- , core OVN
Con respecto al último punto, Neutron PTL publicó el siguiente mensaje: “El equipo de Neutron cree que OVN y el controlador Neutron OVN están construidos sobre una arquitectura moderna que proporciona una mejor base para una solución más simple y eficiente. Estamos viendo una mayor participación en kubernetes-ovn, lo que lleva a una expansión de la comunidad principal de OVN, y nos gustaría que OpenStack también aproveche esta inversión en OVN de Kubernetes.
Por el momento, el controlador Neutron OVN tiene brechas en la funcionalidad admitida en comparación con ML2 / OVS, sin embargo, nuestro equipo está tratando de cerrar estas brechas y creemos que este controlador será el futuro de Neutron y, por lo tanto, queremos convertirlo en el backend Neutron ML2 predeterminado DevStack ".
Hasta el momento, la reacción a esta noticia ha sido bastante positiva, aunque aún existen dudas sobre la transición de los túneles VxLAN a Geneve, las formas de migrar de ML2 OVS a ML2 OVN, así como el rendimiento y la funcionalidad soportada.
Aplicación del nuevo EngineFacade
EngineFacade es un marco sobre sqlalchemy que integra la lógica de la base de datos utilizada en todos los proyectos de OpenStack. Hace varios lanzamientos, pasó por una refactorización, lo que llevó a la aparición de la llamada "nueva EngineFacade". El siguiente paso fue adaptar este marco a OpenStack.
En mi opinión, este tema se incluyó en la agenda del PTG debido a que el trabajo en él se ha prolongado durante varios lanzamientos y aún no se ha completado. Las razones de este desarrollo de eventos son una gran cantidad de cambios necesarios, algunos problemas no triviales en el proceso de adaptación y, según me parece, una falta de motivación y, por tanto, de recursos humanos. Y realmente, ¿por qué cambiar algo que ya funciona y que ni siquiera da un montón de errores? Una respuesta bastante detallada a esta pregunta se describe en la especificación de Mike Bayer. Aquí intentaré dar un breve resumen de las consideraciones en apoyo de EngineFacade para que no tengas que leer este extenso texto:
- El antiguo EngineFacade proporciona API de bajo nivel en lugar de API de alto nivel adaptadas a un caso de uso específico, por lo que esto es esencialmente una fábrica, no una fachada. Como resultado:
- EngineFacade OpenStack
- , ,
- EngineFacade // : reader writer, , .
Suena simple y lógico, entonces, ¿cuál es el problema con la adaptación de EngineFacade? Honestamente, no entré mucho en los detalles, pero parece que la razón principal de los problemas es que en algunos escenarios complejos, el antiguo EngineFacade se usó incorrectamente en Neutron y funcionó (!), Y el nuevo EngineFacade está tratando de hacer todo bien, pero sin embargo, rompe los scripts de trabajo (en mi opinión, un problema bastante típico cuando se trabaja con código heredado). Obviamente, en este caso, primero debe corregir la lógica de estos scripts.
De hecho, no queda mucho por editar, solo un parche, y el equipo central acordó resolver este problema conjuntamente. Por supuesto, cualquier persona interesada puede ayudar con el análisis y la revisión.
Neutron-lib
Se han dedicado varios temas a neutron-lib. Para empezar, permítanme recordarles lo que es para aquellos que no están muy involucrados en el desarrollo de Neutron. En primer lugar, Neutron no es un proyecto único; de hecho, consta de varios repositorios que trabajan en diferentes áreas de la red OpenStack bajo el nombre general de Neutron Stadium, y “neutron” es solo uno, aunque es un proyecto importante. El resto de proyectos son los llamados servicios avanzados (por ejemplo, neutron-lbaas, -fwaas, -vpnaas, -dynamic-routing, etc.) y complementos de terceros / proveedores (por ejemplo networking-midonet, -odl, -ovn). Esta lista incluye proyectos desarrollados por Neutron PTL y el equipo central y que están directamente involucrados en ellos a diario. Para que esto sea posible, se aseguran de que se sigan los principios generales y las reglas de trabajo en todo el Estadio en todos los aspectos del desarrollo: estructura,desarrollo, estilo de código, pruebas, documentación, etc. Para ser honesto, hoy en día esto no es del todo cierto, y la carga principal aún recae sobre los hombros de los responsables del proyecto.
Antes de que se creara neutron-lib, todos los proyectos de redes importaban todo el código común (constantes, interfaces (clases base abstractas), funciones auxiliares y más) del repositorio principal de neutron. Cualquier cambio en dicho código en neutrones podría romper proyectos dependientes. Luego, en la versión de Ocata, se lanzó la iniciativa neutron-lib para resolver este problema: todo el código común ahora debe almacenarse en un repositorio separado y debe tener una versión. Más específicamente, los objetivos se formularon de la siguiente manera:
- Eliminar la dependencia de los subproyectos de Neutron (es decir, eliminar las importaciones directas de neutrones en los subproyectos)
- Haga su tarea en Neutron refactorizando el código o rediseñando la arquitectura de patrón subóptima en las secciones apropiadas de neutron-lib
De hecho, neutron-lib parece una opción en la que todos ganan: como resultado, tanto el Neutron principal como los servicios de proyectos de terceros deberían estar en números negros. ¿Qué salió mal?
Falta de apoyo
Ningún proyecto de código abierto puede existir sin el apoyo de colaboradores y mantenedores, personas que están listas para invertir su tiempo en trabajar en un proyecto. Para neutron-lib, hubo una falta de tales voluntarios y, como resultado, la lógica original dejó de funcionar, es decir, de modo que aquí se almacena todo el código común que podría importarse en lugar de importar neutrones. El mantenedor principal neutron-lib (boden) dejó el proyecto hace algún tiempo. Durante el PTG, se hizo una propuesta para abandonar la idea de trasladar todo el código común a neutron-lib, o incluso trasladar el código neutron-lib de nuevo a neutron. Esta propuesta no fue aprobada por dos razones:
- neutron-lib todavía se usa ampliamente
- neutron-lib tiene algún valor, ya que destaca las interfaces estándar que no se pueden cambiar para no romper varios proyectos a la vez
Después de la discusión, neutron-lib permanece sin cambios, pero la política de reubicación y depreciación del código de neutrones debe actualizarse.
Por supuesto, todo el código nuevo debe compartirse entre neutron y neutron-lib, si es posible. Y eso nos lleva al segundo problema.
Problema de prueba
Otro problema se relaciona con las pruebas durante el desarrollo. Si parte de un parche en neutron introduce un código compartido nuevo o cambia el existente, debe enviarse a neutron-lib mediante reglas. Esto hace que la parte de neutrones del parche dependa de estos cambios de lib. Sin embargo, los parches de neutrones se están probando actualmente en la versión de lanzamiento de neutron-lib para verificar que funcionan con la última versión. Como resultado, dichos parches no pasarán las pruebas en CI.
Ir a probar todos los parches de neutrones con el código neutron-lib del asistente también tiene algunas desventajas. Por ejemplo, no hay garantía de que el asistente de neutrones funcione con la última versión de neutron-lib, y eso es lo que utilizan los usuarios finales.
Estas son las formas de abordar este problema (gracias a Bence Romsics por el excelente resumen):
- , , neutron-lib , neutron .
- , :
- , “foo” neutron-lib, . neutron , “_foo” TODO , , neutron-lib.
- neutron-lib , neutron, _foo “import _foo” “from neutron-lib import foo”.
- Además, puede ejecutar comprobaciones independientes en CI tanto con el asistente como con la última versión de neutron-lib. Pero solo uno de ellos puede votar. Simplemente duplicar el número de tareas supondrá una enorme carga adicional para la infraestructura de OpenStack CI.
Se hicieron tres sugerencias durante la discusión del PTG:
- Utilice el asistente de neutron-lib para "Comprobar CI"; use la versión de lanzamiento de neutron-lib para "Gate CI"; sin embargo, si el parche de neutrones pasa las comprobaciones de "Check CI" y se bloquea en "Gate CI", se verá extraño
- No cambie nada: es mejor ejecutar pruebas en la versión de lanzamiento de neutron-lib. Por ejemplo, esto ahora se hace para OSC (OpenStackClient)
- Ejecute pruebas con el asistente de neutron-lib y agregue una tarea periódica para las pruebas con la versión de neutron-lib
Solución final: cree un nuevo problema sin voto en "Check CI" con neutron-lib de la rama maestra. Básicamente, todo permanece como está, pero será posible comprobar que una característica que incluye cambios en neutron y neutron-lib pasa por CI antes de enviarla a la rama maestra.
Espero que este artículo haya sido útil y le haya ayudado a comprender mejor hacia dónde y por qué se dirige Neutron.
¡Gracias por su atención!