PTG (Project Team Gathering) é um evento onde as equipes de desenvolvimento se encontram para discutir as tarefas, status e planos atuais. O PTG surgiu da conferência mainstream do OpenStack alguns anos atrás.
O PTG foi realizado pela primeira vez online através do Zoom e Jitsi Meet. No entanto, a combinação de imagem e som na reunião tornou esta mudança completamente imperceptível, especialmente contra o pano de fundo das agora familiares reuniões da equipe do IRC.
As sessões de três horas do Neutron foram de terça a sexta-feira. As principais atas da reunião são publicadas no OpenStack Etherpad e na lista de e-mails do OpenStack. A agenda do evento foi formada com base nas propostas dos desenvolvedores do Neutron, e o cronograma do encontro foi elaborado pelo seu presidente, PTL (Project Team Lead) da equipe Neutron Slawek Kaplonski.
Neste artigo falarei sobre 3 tópicos que acho que merecem atenção, e exigem um pouco de explicação.
OVN
Falou-se muito sobre OVN neste PTG, o que não é surpreendente, já que a maioria dos membros da equipe principal representam a RedHat, o principal contribuidor da OVN.
O que é OVN?
- Virtualização de rede L2 / L3 de código aberto para Open vSwitch (OVS):
- Interruptores lógicos
- Roteadores lógicos IPv4 e IPv6
- L2 / L3 / L4 ACLs (grupos de segurança)
- Várias sobreposições de túnel (Geneve, STT e VXLAN)
- Balanceadores de carga lógicos
- Gateways L2 lógico-físicos baseados em TOR
- Gateways L2 / L3 lógico-físicos baseados em software
- Funciona nas mesmas plataformas que OVS:
- Linux
- Recipientes
- DPDK
- Integração com:
- OpenStack Neutron
- Docker swarm
- Kubernetes
Arquitetura OVN
“OVN em 75 palavras.
A Rede Virtual Aberta é operada pelo projeto OVS e desenvolvida pela equipe OVS original. Esta decisão é uma tentativa de redesenhar o plano de controle ML2 / OVS com base em anos de experiência. Ele deve ser usado com OpenStack e Kubernetes. OVN é construído em uma nova arquitetura que abandonou o conceito de agentes Python interagindo com o serviço Neutron API via RabbitMQ em favor de daemons C se comunicando via OpenFlow e OVSDB. ” - Slawek Kaplonsky, Neutron PTL.
Inicialmente, o driver Neutron OVN foi desenvolvido como um projeto separado no estádio Neutron - networking-ovn, e na versão Ussuri foi incluído no repositório principal do Neutron.
Desta forma, esta solução elimina o principal problema do ML2 / OVS - RabbitMQ, que é uma vantagem indiscutível, e em geral “O objetivo do design da OVN é ter uma implementação com qualidade de produção que possa operar em uma escala significativa”. No entanto, o OVN oferece suporte à funcionalidade disponível ao usar ML2 / OVS? Parece que isso não é totalmente verdade, o que se tornou um dos tópicos de discussão no EPP. Como resultado, várias lacunas foram destacadas (uma lista completa está disponível na página do projeto). Em primeiro lugar, os desenvolvedores notaram a ausência ou suporte incompleto para redes roteadas, alguns recursos de QoS, BGP e zonas de disponibilidade. Embora a equipa OVN esteja preparada para fazer face a tudo isto, durante a reunião admitiram que esta não era uma prioridade para eles, uma vez que os interesses internos eram mais importantes. Além disso, o desenvolvimento do ML2 / OVS, é claro,não pausa, o que significa que novos espaços podem aparecer.
No entanto, na minha opinião, o principal problema com OVN é que ainda não é amplamente utilizado e não foi testado em grandes instalações. Além disso, existem algumas perguntas sobre alta disponibilidade:
- Um dos componentes principais, ovn-northd, atualmente suporta apenas o modo HA ativo / passivo, ativo / ativo está planejado apenas por enquanto
- Outro componente central, ovsdb-server, também suporta apenas o modo ativo / passivo
É possível que o último ponto esteja realmente desatualizado, já que o suporte para o cluster ovsdb (baseado no algoritmo Raft) foi adicionado desde OVS 2.9, mas não está claro se isso foi testado na versão com OVN e OpenStack. Por exemplo, o tíquete associado em openstack-ansible ainda não foi fechado.
Também é preocupante que OVN usa túneis Geneve em vez de VxLANs, o que afeta as configurações de MTU (os cabeçalhos Geneve são maiores que VxLANs) e suporte para processamento de túnel acelerado por hardware.
Seja como for, o projeto está ganhando impulso rapidamente e parece que em alguns lançamentos OVN se tornará um plugin básico do Neutron. Além disso, durante o PTG, os desenvolvedores da equipe principal concordaram em tornar OVN o plug-in padrão para DevStack.
Aonde essas mudanças levarão:
- OpenStack Neutron CI,
- ML2/OVS ( )
- Neutron CI , ML2/Linuxbridge ML2/OVS – ,
- , core OVN
Em relação ao último ponto, Neutron PTL postou a seguinte mensagem: “A equipe Neutron acredita que OVN e o driver Neutron OVN são construídos em uma arquitetura moderna que fornece uma base melhor para uma solução mais simples e eficiente. Estamos vendo um envolvimento maior no kubernetes-ovn, levando a uma expansão da comunidade OVN central, e gostaríamos que o OpenStack aproveitasse esse investimento em OVN do Kubernetes também.
No momento, o driver Neutron OVN tem lacunas na funcionalidade suportada em comparação com ML2 / OVS, no entanto, nossa equipe está tentando preencher essas lacunas e acreditamos que este driver será o futuro para Neutron e, portanto, queremos torná-lo o backend Neutron ML2 padrão para DevStack. "
Até agora, a reação a esta notícia é bastante positiva, embora ainda existam dúvidas sobre a transição dos túneis VxLAN para Geneve, como migrar de ML2 OVS para ML2 OVN, bem como desempenho e funcionalidades suportadas.
Aplicação do novo EngineFacade
EngineFacade é uma estrutura baseada em sqlalchemy que integra a lógica do banco de dados usada em todos os projetos OpenStack. Vários lançamentos atrás, ele passou por refatoração, o que levou ao surgimento da chamada “nova EngineFacade”. A próxima etapa foi adaptar essa estrutura ao OpenStack.
Na minha opinião, este tema foi incluído na agenda do EPP devido ao fato de que os trabalhos nele se arrastam por vários lançamentos e ainda não foram concluídos. As razões para este desenvolvimento de eventos são uma grande quantidade de mudanças necessárias, alguns problemas não triviais no processo de adaptação e, ao que me parece, falta de motivação e, portanto, de recursos humanos. Na verdade, por que mudar algo que já funciona e nem dá um monte de bugs? Uma resposta bastante detalhada a essa pergunta é descrita na especificação de Mike Bayer. Aqui, tentarei fornecer um breve resumo das considerações a favor do EngineFacade para que você não precise ler este texto longo:
- O antigo EngineFacade fornece APIs de baixo nível em vez de APIs de alto nível adaptadas a um caso de uso específico, portanto, é essencialmente uma fábrica, não uma fachada. Como um resultado:
- EngineFacade OpenStack
- , ,
- EngineFacade // : reader writer, , .
Parece simples e lógico, então qual é o problema com a adaptação EngineFacade? Para ser honesto, não entrei muito em detalhes, mas parece que o principal motivo dos problemas é que em alguns cenários complexos o antigo EngineFacade foi mal utilizado no Neutron e funcionou (!), E o novo EngineFacade está tentando fazer tudo certo, mas no entanto, ele quebra os scripts de trabalho (na minha opinião, um problema bastante típico ao trabalhar com código legado). Obviamente, neste caso, você deve primeiro corrigir a lógica desses scripts.
Na verdade, não há muito o que editar - apenas um patch, e a equipe principal concordou em resolver o problema em conjunto. Claro, qualquer pessoa interessada pode ajudar com a análise e revisão!
Neutron-lib
Vários tópicos foram dedicados à libido de nêutrons. Para começar, deixe-me lembrá-lo do que é para aqueles que não estão fortemente envolvidos no desenvolvimento do Neutron. Primeiro, Neutron não é um único projeto - na verdade, ele consiste em vários repositórios trabalhando com diferentes áreas da rede OpenStack sob o nome geral Neutron Stadium, e “neutron” é apenas um, embora seja um grande projeto. O restante dos projetos são os chamados serviços avançados (por exemplo, neutron-lbaas, -fwaas, -vpnaas, -dynamic-routing, etc.) e plug-ins de terceiros / fornecedores (por exemplo networking-midonet, -odl, -ovn). Esta lista inclui projetos que são desenvolvidos pela Neutron PTL e a equipe principal e estão diretamente envolvidos neles diariamente. Para tornar isso possível, eles garantem que os princípios gerais e regras de trabalho em todo o Estádio sejam seguidos em todos os aspectos do desenvolvimento - estrutura,desenvolvimento, estilo de código, teste, documentação, etc. Para ser honesto, hoje isso não é totalmente verdade, e o fardo principal ainda recai sobre os ombros dos mantenedores do projeto.
Antes de a lib de nêutrons ser criada, todos os projetos de rede importavam todo o código comum - constantes, interfaces (classes básicas abstratas), funções auxiliares e mais - do repositório principal de nêutrons. Quaisquer mudanças nesse código em nêutrons podem quebrar projetos dependentes. Então, no lançamento do Ocata, a iniciativa neutron-lib foi lançada para resolver este problema: todo o código comum agora deve ser armazenado em um repositório separado e deve ser versionado. Mais especificamente, os objetivos foram formulados da seguinte forma:
- Remover dependência de subprojetos de nêutrons (ou seja, remover importações diretas de nêutrons em subprojetos)
- Faça seu dever de casa no Neutron, refatorando o código ou redesenhando a arquitetura de padrão subótima nas seções apropriadas da lib de nêutrons
Na verdade, a liberação de nêutrons parece uma opção ganha-ganha: tanto o Neutron principal quanto os serviços de projetos de terceiros devem ficar no azul como resultado. O que deu errado?
Falta de suporte
Nenhum projeto de código aberto pode existir sem o apoio de contribuidores e mantenedores - pessoas que estão prontas para investir seu tempo trabalhando em um projeto. Para neutron-lib, havia uma falta de tais voluntários e, como resultado, a lógica original parou de funcionar, ou seja, de modo que todo o código comum fosse armazenado aqui e pudesse ser importado em vez de importar nêutrons. O principal mantenedor neutron-lib (boden) deixou o projeto há algum tempo. Durante o PTG, foi feita uma proposta para abandonar a ideia de portar todo o código comum para neutron-lib, ou mesmo para portar o código de neutron-lib de volta para neutron. Esta proposta não foi aprovada por dois motivos:
- neutron-lib ainda é amplamente utilizado
- neutron-lib carrega algum valor, pois destaca as interfaces padrão que não podem ser alteradas para não quebrar vários projetos de uma vez
Após a discussão, a lib de nêutrons permanece inalterada, mas a realocação do código de nêutrons e a política de depreciação precisam ser atualizadas.
Claro, todo código novo deve ser compartilhado entre a lib de nêutrons e a lib de nêutrons, se possível. E isso nos leva ao segundo problema.
Problema de teste
Outro problema está relacionado aos testes durante o desenvolvimento. Se parte de um patch em nêutrons introduz um código compartilhado novo ou altera o código compartilhado existente, ele deve ser enviado para a lib de nêutrons pelas regras. Isso torna a parte do nêutron do patch dependente dessas alterações de lib. No entanto, os patches de nêutrons estão sendo testados na versão de lançamento do neutron-lib para verificar se funcionam com a versão mais recente. Como resultado, esses patches não passarão nos testes de CI.
Testar todos os patches de nêutrons com código de lib de nêutrons do assistente também tem algumas desvantagens. Por exemplo, não há garantia de que o assistente de nêutrons funcionará com a versão mais recente da lib de nêutrons, que é o que os usuários finais estão usando.
Aqui estão as maneiras de resolver esse problema (obrigado a Bence Romsics pelo excelente resumo):
- , , neutron-lib , neutron .
- , :
- , “foo” neutron-lib, . neutron , “_foo” TODO , , neutron-lib.
- neutron-lib , neutron, _foo “import _foo” “from neutron-lib import foo”.
- Além disso, você pode executar verificações separadas no CI com o assistente e a versão mais recente da lib de neutrons. Mas apenas um deles pode votar. Simplesmente dobrar o número de tarefas colocará uma enorme carga adicional na infraestrutura de CI do OpenStack.
Durante a discussão no EPP, três propostas foram feitas:
- Use o assistente neutron-lib para “Check CI”; use a versão de liberação de neutron-lib para "Gate CI" - no entanto, se o patch de nêutrons passar nas verificações de "Check CI" e travar em "Gate CI", parecerá estranho
- Não mude nada: é melhor executar testes na versão de lançamento neutron-lib. Por exemplo, isso agora é feito para OSC (OpenStackClient)
- Execute testes com o assistente neutron-lib e adicione uma tarefa periódica para testes com a liberação neutron-lib
Solução final: crie um novo problema sem votação em “Check CI” com neutron-lib do branch master. Basicamente, tudo permanece como está, mas será possível verificar se um recurso que inclui alterações na lib de nêutrons e nêutrons passa por CI antes de enviá-lo para o branch master.
Espero que este artigo tenha sido útil e ajudado você a entender melhor para onde e por que o Neutron está indo.
Obrigado pela atenção!