 Olá, de novo. Pra quem não me viu ainda, meu nome é Helen. Eu trabalho na colabora, sou desenvolvedora. Vou falar um pouco aqui sobre os planos de ter releases, versões, oficiais de Debian para o mundo de cloud, de nuvem. Então, a gente vai falar um pouco do contexto e o objetivo. Por que a gente quer isso? A visão geral do plano de implementação, os detalhes de cada passo que a gente vai precisar. Uma coisa, vou usar a palavra build aqui como se fosse um verbo no português, buildar, que é basicamente compilar e gerar a imagem. Então, a gente vai falar dos detalhes de cada passo, de build, de teste, dessa nature, de publicação, dessas imagens, teste de integração contínua, a infraestrutura que precisamos para fazer isso e o estado atual. Então, só um disclaimer aqui, a informação que eu estou trazendo para vocês foi que foi discutido em um sprint, um sprint é uma reunião que tem, que as pessoas vão fisicamente participam, que tem de vários times o Debian, e teve um sprint de cloud, do time de cloud, no passado, em outubro do ano passado. Ups, porque ele está mechando só assim. E eu vou apresentar aqui o que foi discutido. A maioria das coisas não foram implementados ainda, foram só decididas. Então, todas essas coisas que eu vou apresentar são sujeitas à modificação. Então, estou apresentando aqui para vocês qual é o plano de ação que foi decidido, mas tem muita coisa ainda para ser implementado, e é possível que seja modificado durante o meio do caminho, a gente veja que não está bom e a gente modifique. Certo? Contexto. Então, aqui quando a gente vai falar de cloud, a gente vai falar de IAAS, que é Infrastructure as a Service, que é, basicamente, uma máquina remota que algum provedor de cloud disponibiliza para você. E, geralmente, é uma máquina virtual, mas não necessariamente. Existem servidores, provedores, que a gente chama de bare metal providers, que realmente te dá uma máquina física e te dá alguma maneira de instalar qualquer coisa nessa máquina física em algum lugar. E isso é legal, porque você às vezes se preocupa em performance e não quer dividir sua máquina com mais ninguém. Uma máquina virtual você está dividindo uma máquina física com várias pessoas. Então, exemplos de provedores, certo? Nós temos a Amazon, a AWS, temos a Digital Ocean, temos a Google, Cloud Engine, temos a Microsoft Azure, e nós vamos falar também aqui de plataformas, então OpenStack, por exemplo. E eu vou falar mais dessas aqui, porque essas aqui estão mais envolvidas no time de cloud. E o que é legal do Debian é que a gente vê no mundo empresas que são concorrentes, mas que elas trabalham juntas contribuindo. Então, nesses provedores, quando você pega uma máquina virtual, eles provem para vocês umas imagens pré-prontas que, basicamente, você só seleciona que imagem você quer, dá um clique e instala isso para você na sua máquina virtual, ou máquina real. E Debian é uma delas. Então, por exemplo, aqui na Amazon dá para ver o Debian lá, que você pode simplesmente clicar em launch now, que ele vai te dar uma máquina Debian. No Google Cloud Engine também você pode simplesmente dar um start ali em uma máquina Debian. Na Microsoft, Azure também tem um monte de distribuição Linux, lá você pode simplesmente escolher e instalar uma máquina Debian. E essas imagens, elas não são iguais entre os provedores, certo? Pois cada provedor tem funcionalidades diferentes, e geralmente essas imagens possuem algumas funcionalidades, precisam se integrar de alguma forma com as funcionalidades que o provedor tem. Por exemplo, adicionar um usuário pela interface gráfica, às vezes você não precisa logar na máquina e digitar o comando para criar um novo usuário. Ele te fornece uma API, você pode entrar na interface gráfica, apertar um botão, criar um novo usuário, usar alguma ferramenta de, o que a gente chama CLI, o cliente, ou fazer requestos da API diretamente. Então pode adicionar um usuário, pode adicionar uma interface de rede, você pode adicionar um script para ser executado, quando o sistema bota, quando o sistema desliga, e cada provider de cloud de máquina da nuvem tem seu conjunto. Então essas imagens não são idênticas, certo? E para que essas funcionalidades, dando um pouco de contexto de definição, para que essas funcionalidades funcionem, tem que ter o que a gente chama de agents rodando na imagem, porque é um agent, é basicamente um demo, é um programa que roda em background, que roda dentro da sua máquina virtual, ela prepara a sua máquina virtual, faz algumas configurações, e ela escuta requestos do seu provedor de cloud. Então quando você clica lá na interface, quero adicionar um usuário, que na verdade está acontecendo, um comando está sendo enviado pela rede para criar um usuário, e essa máquina tem esse demo rodando lá escutando por essa requisição, e ele vai lá e faz o que você faria na mão por você. Certo? Então cada provedor implementa o seu, e o legal, pelo menos os provedores que eu mencionei, é que esses agents aqui são open source. Você pode lá verificar o código, verificar se eles não estão fazendo nada malicioso no seu sistema. Mas é sempre duvidoso se... E é isso que a gente vai abordar, é sempre duvidoso se o que está realmente na imagem que você está rodando equivale realmente ao código-fonte que você viu, certo? Então a situação atual que temos hoje, cada provedor build-up gera a sua própria imagem do Debian, os softwares de agents não estão no Debian, ainda não estão empacotados, nós temos empacotados para Debian, mas eles não estão ainda no repositório, ninguém ainda se propôs a mantê-los. O ruim é que como cada provedor faz o seu, a gente estava vendo que os testes também não são muito elaborados, é basicamente a imagem buta, e se os programas que você imaginava que estariam rodando, estão rodando. Tem outras cheques de segurança, mas não é muito testado, varia na verdade, a qualidade das imagens, dependendo do provedor, varia bastante. E o que é ruim, que você não vai conseguir dar uma segurança para o usuário Debian, que quer usar Debian na Cloud, da qualidade da imagem que eles estão rodando, certo? Então o objetivo é a gente gerar, junto com as releases, aqueles CDs de Debian Stretch, enfim, quando a gente lança uma nova versão, em vez de gerar só o CD, a gente também gera imagens para várias plataformas de cloud, imagens oficiais. Então a gente teria uma imagem que vai funcionar na Amazon, uma imagem voltada para o Google Cloud, uma imagem para o Digital Ocean, para OpenStack, uma imagem para Docker, para VAL Grant, para VirtualBox, e diversas outras, certo? E que essa imagem seja testado e verificado pela comunidade. Então o usuário vai poder ter mais segurança que aquela imagem é OK. E o legal disso é que, ao invés desses provedores, cada um trabalhando por si, a gente coloca eles para trabalharem juntos e contribuindo para a comunidade, trabalhando junto com a comunidade, ao invés de fazer coisas separadas que não retornam nada para a gente, certo? E evitar retrabalho. E além disso, quando as pessoas trabalham juntas, quando se resolve um bug em um e um provedor, esse bug vai ser resolvido para todos os outros. Então garante uma qualidade maior para todos os usuários de Debian, mesmo na Cloud. Certo? Então, como a gente quer fazer essas imagens oficiais? Temos alguns requisitos. Então o requisito é, essas imagens só vão conter pacotes que sejam na sessão main, ou seja, que elas sejam livres, de acordo com o que o Debian acha que é livre, a definição de livros de Debian seguindo a Debian for Software Guidelines. E que essas imagens sejam geradas, sejam bildadas nas máquinas do Debian, que a gente tem mais confiança, que tem algum processo de controle de qualidade que foram assinadas pelo Debian, então você pode verificar que aquela imagem realmente veio da comunidade Debian, e que a ideia é ter uma infraestrutura para automatizar todas essas releases de várias plataformas, justamente para... Bom, a gente vai começar com alguma só, mas quem quiser adicionar, por exemplo, a gente vai começar com Amazon, Google Cloud e Digital Ocean, mas quem quiser se interessar, vamos adicionar uma imagem para Linode, que seja fácil isso, é só alguém se disponibilizar a trabalhar nisso, certo? E a ideia é gerar imagens que sejam de fácil integração nessa plataforma, então é por isso que a gente tem uma imagem para cada plataforma, que a imagem vai ser voltada para lá. É imagem completa, como se fosse que você consegue colocar na máquina virtual da boot. É tudo completo. Inclusive o Kernel respondeu e perguntou. Certo, então, plano de implementação, a visão geral, como a gente vai fazer a infraestrutura para fazer isso. Então, a ideia é... Nós temos que... Então, plano de implementação, o que a gente tem que fazer? Build a imagem, testar a imagem, assinar ela para testar que ela é do Debian, que nós confiamos nessa imagem, que foi feita por nós, e publicar, legal? E, além disso, nós queremos ter algum esquema automatizado de teste de integração contínua. A gente chama de CI, Continuous Integration, para descobrir bugs o mais rápido possível e resolvê-los o mais rápido possível. Então, como a gente vai fazer isso para fazer releases oficiais do Debian para a versão estável, para o stable? Então, todos os passos que eu falei para vocês, desde gerar a imagem até a publicação, quando se trata de stable, a gente vai fazer manual, porque a gente quer ver, certinho, em seu controle muito próximo. Isso é feito, basicamente, uma vez a cada release, mais algumas autorizações de segurança, cada autorização de segurança. Enfim, a ideia é a gente vai fazer esse processo, refazer esse processo toda vez que a gente tiver uma release, toda vez que a gente tiver uma point release, que é quando a gente integra os updates dentro do stable, toda vez que a gente tiver mudanças no repositório de security stable e mudanças em stable updates, basicamente. Era isso o plano. E aí, a gente vai refazer esse processo e publicar uma nova versão da imagem. Além disso, além desse processo para realmente a publicação de uma versão stable, a gente vai ter um outro que é para controle de qualidade, que a gente chamou de stable QA, que não vai ser publicado, certo? Para realmente verificar o time de controle de qualidade, verificar aquela imagem, tá ok? Então, a gente vai buildar, vai testar, isso aí vai ser manual para o time de qualidade, verificar manualmente as coisas. Vamos assinar, nem publicar, e a execução vai ser quando a gente precisava gerar um novo stable, aí é o time de qualidade que vai decidir, vai ter verificações manuais, e é uma coisa que estava em discussão na comunidade se a gente consegue publicar os logs para não esconder nada, para o time de qualidade publicar o que eles analisaram. E além disso, além dessa infraestrutura, a ideia é ter uma outra infraestrutura, que é também voltado para testes, só que não para o time de controle de qualidade, mas para qualquer um, na verdade, que possua, eu sei, o bridge stable, e também outros repositórios privados, e que a gente consegue buildar e testar de forma automática, eu acho que foi falado diário, ou toda vez que entra um pacote novo, em algum repositório privado, porque a ideia é que, antes de você, vamos supor, você precisa atualizar um pacote, antes de você, você como client provider, você tem que mudar ali o seu agent, então ao invés de você enviar direto o que você consertou para o stable, você não quer quebrar essa imagem, você quer testar ele direito, então você coloca ele num repositório privado, sei lá, um PPA, alguma coisa que você tenha controle, e que possibilite você testar, se vai integrar bem com o sistema antes de você enviar para o stable, e antes da nova imagem ser lançada. Então a ideia é sempre identificar os erros, antes de incluir o pacote na imagem de stable. Certo, é isso aí para o stable. Para o testing, a ideia é, a parte de publicação, testar, assinar e publicar, vai ser feita automático, e vai ser feita automático de uma forma semanal. Então toda semana lá, vai ter uma nova imagem do testing que você pode usar na sua infrastructure cloud. E se o build de alguma dessas imagens semanais falha por alguma razão, não é um problema, porque, enfim, nós estamos no testing e, enfim, espere a semana seguinte. Além disso, além dessas habilidades oficiais, também queremos ter uma outra infraestrutura do testing, que é para testes diários, que ele vai executar isso diariamente, fazer todo o processo de build de testes automaticamente, mas essa imagem não vai ser assinada, nem publicada, é só para testes mesmo, é a ideia de identificar e notificar os problemas o mais rápido possível. Além disso, é lógico, toda essa infraestrutura é legal, mas nós precisamos também que seja possível você fazer testes no seu próprio computador. Então a gente precisa de ter toda essa infraestrutura codada de uma forma fácil de ser setapiada no seu computador para que você possa verificar que tudo está ok. Vamos ver o detalhe de cada passo, como a gente vai fazer cada passo. Só querendo reforçar que essa infraestrutura ainda não está implementada no Debian. Então, para gerar as imagens, a ferramenta que a gente escolheu para isso se chama FI, Full Automatic Installation. Ela é uma ferramenta feita pelo Tomas Land e ela foi escolhida para gerar as imagens oficiais de Debian para a Cloud. Então, cada, como cada imagem para cada proveedor, vai ter uma imagem diferente, então você tem uma configuração dentro do FI por plataforma Cloud. Uma lista de pacotes a serem instaladas, por exemplo, o pacote da Google vai instalar o wading da Google, o pacote da Amazon. Não, a Amazon não tende. A pacote da Microsoft vai instalar o wading da Microsoft da Azure e também tem uma lista de configurações. Por exemplo, a Google ela não permite de forma nenhuma que você faça SSH na máquina por senha, mas a Azure permite e aí você tem que alterar depois. A digital ouxa também permite na hora que você cria a imagem, você tem uma opção se você quer colocar uma senha ou se você não permite. Então, cada uma faz de uma forma diferente, então você tem uma configuração por plataforma e quais são as portas que estão abertas para conexão. Cada uma oferece alguns serviços diferentes, então tem um conjunto de portas de diferença. Na verdade, a maioria vai ser igual e vai ser comum com eles e o legal do FI é que você tem a maneira que o FI coloca as configurações é que você coloca configurações genéricas, depois coloca as configurações mais específicas e assim vai. Então, a base inteira parte de um só ponto e aí você vai especificando as diferenças e isso é revisado pelo time de Cloud. Então, como é que o FI é executado em termo de segurança? Então, quando você vai buildar uma nova imagem de Cloud, você não vai fazer isso na máquina, porque é meio inseguro. Então, o que você faz? Você gera uma máquina virtual que vai executar em cima do KVM e executa o FI dentro dessa máquina virtual. Dentro dessa máquina virtual vai ser gerado a imagem depois que acabar o processo você copia essa imagem dessa máquina virtual para fora e joga fora essa máquina virtual. Você está isolando o ambiente por motivo de segurança. Certo. Esse é o passo de build. Agora vamos para o próximo, que é o passo de testing. Então, nós temos três tipos de testes diferentes. Então, temos testes de estáticos, testes locais e testes remotos. Os testes estáticos ele basicamente faz uma análise estática da imagem lá. Você tem que ser gerado uma imagem ponto raw daquele provider. Você vai montar essa imagem e verificar que os arquivos que você esperava estão lá as configurações que você esperava e você precisa rodar essa máquina. Os testes locais você simplesmente vai tentar botar essa imagem em uma máquina virtual local, sem usar o provider e verificar algumas funcionalidades básicas. O legal é que aqui a gente consegue detectar erros muito antes. A gente também não precisa gastar créditos da cloud para poder verificar. Então, a gente pode pegar vários erros aqui. E os testes remotos, que é quando você realmente faz o deploy, que a gente fala, que é botar essa imagem num provedor de cloud. A ideia de fazer isso é que como a gente falou, cada cloud implementa uma API diferente, tem funcionalidades diferentes, então você teria testes de integração para ver se aquela imagem DEB você consegue integrar com aquela plataforma. O terceiro passo é assinar, enfim, tem que ter uma infraestrutura para assinar aquela imagem e para versionar a imagem também que fizemos. E a publicação que temos que enviar as imagens para os devidos lugares, não é só copiar e deixar lá no site. O legal é que nós estávamos pensando que quem fez uma prova de conceito já um image locator que você consegue definir, que é uma ferramenta de busca buscar alguma imagem, porque a gente estava discutindo também ter diversos flavors, pode ter um Debian e isso aqui, isso é uma possibilidade que a gente deixou para baixa prioridade, talvez a gente faça uma coisa em discussão. Ter diversos sim, um Debian otimizado para gráficos, um Debian otimizado para nossos servidores, vários devs que você poderia gerar imagens e distribuir, isso de uma forma fácil para as pessoas localizarem e instalarem eris na plataforma. Isso aí. E além desses passos nós queremos colocar um sistema de integração contínua que são tédios contínuos para pegar os erros mais rápido possível e foi levantado algumas possíveis ferramentas para fazer isso, que é o Jenkins Rundack ou Tube Definer para ser definido depois, foi uma discussão bem não aprofundamos tanto na discussão e enfim, usar algumas ferramentas dessa para orquestrar e automatizar aqueles passos anteriores de build, test assinar e publicar e deixar as coisas automáticas mas ainda seguros. E um mecanismo de notificação em caso de erros. Teve erro no build e a gente quer receber um e-mail para alguém lá verificar manualmente o que aconteceu. Então, a infraestrutura como vai ser? Tem uma máquina muito legal no Debian que se chama Casulana é uma máquina bem fortinha é um Cheon de 22 cores Hyper-Trading 2x22 com 374 GB de memória bem parruda e usada para fazer releases então a pedaço de build vai ser executado nessa máquina então a ideia é ser usado como um usuário separado que a gente chamou de CloudBuild dentro da Casulana que vai fazer aquele negócio de geral uma máquina virtual, rodar o FI dentro para gerar a imagem vai usar usando o espaço de usuário e KVM aí depois vem os testes que também vão ser executados na Casulana como outro usuário por motivo de segurança também usando o espaço do ar e também máquinas virtuais e aí os testes remotos lógico, não dá para executar a ideia de ser remoto então a ideia é fazer deploy dessas imagens diretamente nos provedores e o legal é que a maioria dos provedores oferecem dão créditos para a gente para a gente poder testar lá gratuitamente e depois temos que fazer assinatura dessa imagem publicar e aí não foi exatamente definido para onde publicar certo? então onde aqui estamos em tudo isso o estado atual o Amazon a AWS por enquanto é a única que usa FI se vocês entraram na Amazon e falarem, ah, Instalar Debian aquela imagem foi gerada pela ferramenta FI que a gente escolheu e nós temos um rascunho de testes de integração que está funcionando na AWS no Google Cloud que eu inclusive escrevi partes dele mas foi trabalho de um dia, dois dias, não é muito formal temos um setup na casulana eu acho que não sei se já tem os usuários mas as pessoas já estavam trabalhando nisso os agents como eu comentei que cada provider tem ainda não estão no Debian não sei se algum já está mas ninguém foi lá e falou que era manter as coisas estão caminhando bem devagar não tem nada em produção isso aqui é só um plano de ação então tem muito trabalho que pode ser feito aí e tem um possível conflito de interesse entre com os provedores pois eu escutei de provedor que vamos supor você adiciona uma nova funcionalidade na sua plataforma de cloud então você precisa atualizar o agent certo? com uma nova funcionalidade vamos supor agora eu sei lá, eu consigo eu quero colocar uma funcionalidade que a pessoa sei lá, mude a imagem de background da sua máquina virtual pela interface gráfica você dá um upload na imagem, ela envia para a sua máquina e você muda a imagem então você tem que atualizar esse agent e esses provedores bom, esse foi um exemplo simples mas tem outras funcionalidades mais complexas e esses provedores têm interesse em manter todas as imagens atualizadas inclusive o stable só que aí tem um conflito que o stable não é para adicionar novas funcionalidades é só para resolver bugs certo? e então alguns estão golpeando atrás falando assim por que eu vou investir para a imagem de Debian se eu vou ter que atualizar minha própria imagem de qualquer jeito com esse negócio atualizado então eu vou ter que manter duas infraestruturas ajudar o Debian ter uma infraestrutura interna a ideia era mais tentar fazer com que eles focassem toda a tensão no Debian e deixar de usar a infraestrutura deles que contribui de volta então fica tem esse conflito entre investir no Debian e criar a sua própria imagem só que foi discutido tem controversas aí que assim algumas pessoas falaram que os agents não são pacotes base do sistema certo? eles são só usados pela plataforma cloud e então se você der um upgrade nele dos agents a probabilidade de quebrar o sistema é baixa não é muito alta mas mesmo assim fica o debate então foi discutido que se a gente mostrar que aquela atualização foi bem testada que funciona bem que não quebra então talvez a gente conseguiria fazer se fosse bem justificado conseguiria colocar esse agent no stable mas enfim é um debate ainda e também assim o provedor tem todo o interesse em estabilidade então quando ele fizer update lá no agent ele vai testar porque se não funcionar vamos supor que a gente consiga fazer com que eles foquem toda a atenção no Debian se não funcionar eles são muito prejudicados porque as pessoas usuárias não vão conseguir mais usar a imagem Debian é de forma esperada do da plataforma de cloud dele enfim e essa discussão não está clara ainda dentro do time e é isso que eu tinha para falar para vocês perguntas você comentou antes que existe a intenção do Debian produzir imagens de algumas flavors mas isso não ficou bem claro não tem uma prioridade muito baixa mas distribuições oficiais como por exemplo a versão do Debian com o kernel do FreeBSD foi discutido alguma coisa sobre isso se a intenção é já colocar essa distribuição oficial junto nesse pacote já tem intenção de produzir ela com o kernel porque hoje se eu não me engano das maiores ali eu acho que só a digital ocean fornece o FreeBSD nativo mas o Debian com o kernel do FreeBSD eu ainda não vi é bom para ser sincero isso não foi discutido no sprint mas o é porque o foco é ter o básico primeiro e depois discutir o que a gente pode fazer a mais o Fai que foi a ferramenta para build teoricamente ele é flexível suficiente para você configurar ele para buildar uma imagem com você então se no futuro você se interessa depois que toda infraestrutura estiver no ar se alguém se interessa em colocar lá a configuração fazer os testes e colocar isso no processo de release aí pode ser feito eu acho que eu fiquei meio perdido esse sprint foi do que? foi sprint de cloud o time de cloud do Debian e esse é o time que já faz as imagens hoje por exemplo eu vi que tem uma imagem de docker meio oficial do Debian tem, isso foi discutido mas ficou meio assim porque a galera de docker não foi então a gente tanto chamar eu acho mas não sei se eles não respondem eu não sei o que aconteceu direito teve algum desencontro que eles não foram mas essa imagem oficial ela se diz oficial mas eu acho que ela não é assinada pelo Debian se diz oficial porque são Debian developers mas eu acho que eles não é assinado pela chave do Debian não é oficial mesmo quantas pessoas estão participando desse todo esse processo mais ou menos do time esse sprint foi aonde? foi em siato eu tenho uma foto das pessoas eu estou bem por fora disso foi o outro do ano passado deixa eu ver se eu consigo abrir essas são as fotos das discussões tinha uma foto do grupo mas não está aqui mas enfim foi mais ou menos umas 15 pessoas que foram e se eu quiser contribuir o que eu preciso conhecer para conseguir contribuir então aí primeiro é clarificar alguns pedaços alguns pontos que não estão tão claros outro é trabalhar no FI verificar que o FI realmente build as imagens que deveriam build verificar que essas imagens testar tem um trabalho de teste na verdade a infraestrutura de teste é muito pequena não está nem próximo do que a gente quer tem muito trabalho de teste então é chegar, tem teste para o FI e codar os testes que faz essa análise estática a gente não tem nada que roda a máquina e verifica se faz algumas verificações a gente tem uma lista tem uma lista no GOB com vários testes que a gente quer fazer lá então você pode entrar no GOB não sei se conhece o GOB é tipo o WaterPad é um software você manda conectar no GOB.devm.org era para estar aberto aqui e aí tem várias anotações aqui está o COUNTCPRINT tem uma pasta de sprints e aqui tem o COUNTCPRINT 2017 tem a agenda configuração dos pacotes aqui teste suíte e aí tem os planos que a gente quer testar e seria pegar essa lista e começar a implementar eu acho que isso é a parte mais trabalhosa também o FI a gente tem estrutura que faz de forma segura que faz um launch de uma VM e roda o FI lá dentro e pega o resultado isso também a gente não tem só mais uma coisa que estou meio perdido quando você gera uma imagem para testar na sua máquina você sobe ela com QEMU, Davi alguma coisa assim isso, basicamente é mais perguntas? tem muitas peculiaridades entre fazer uma imagem para Amazon e para Google e você consegue começar algum exemplo? certo, então eu posso falar da Amazon da Google que a gente estava codando eu estava mais codando a parte do teste do Google o Tomas o nome dele o nome dele estava ajudando a fazer da Amazon o que é mais os testes de integração os testes básicos de Debian são todos iguais mas é mais você testar se aquela imagem gerada realmente conversa com a API certinho se não tem uma porta fechada a porta que aquele serviço usa daquele provider não está fechada por exemplo tem essa diferença que você consegue testar consigo criar um usuário consigo usar a API por exemplo esses testes eles ficam aonde? estava meio que foi meio feito assim jogaram ele em um IT lab eu acho que agora está no salsa posso verificar para você porque faz tempo que ninguém toca neles essa é uma iniciativa recente sim sim no sprint tinha pessoas representando a Microsoft Azure tinha pessoas representando a Digital Ocean tinha pessoas representando OpenStack foram pessoas representando a Google também durante um período o curioso é que esse sprint foi rostiado pela Microsoft eles estão apoiando e um pouco Debian e que mais tinha pessoas da SPI que queriam garantir que tudo o que a gente está fazendo está de acordo com as normas do Debian pessoas que estavam mantendo tem um outro software chamado CloudNit que é usado para configurar máquinas imagens que é usado pela Amazon você não me engano mas pode ser usado por todo mundo estava lá também foi bem consultivo eu achei uma pergunta ali o microfone eu sou cliente da Digital Ocean e eu já reparei que eles alteram quando você cria uma imagem de um server novo eles alteram a lista do apt para os repositórios deles se você fosse criar um server na AWS ou na Digital Ocean ou na Azure você usaria os repositórios deles ou só os oficiais do Debian eu não sabia isso do Digital Ocean eu sei que o Google da Amazon eles usam praticamente o Debian só instala o pacote que é o CloudNit e eles seguem os repositórios oficiais do Debian mesmo a Google adicionou só mais um repositório para você instalar o ADN dela mas é mais é que eu não sei se eles tem só um mirror se ele está download talvez ou se eles modificaram alguma coisa eu ainda nunca olhei em detalhes eu não vou saber te responder mas a ideia que essa imagem oficial vai seguir os repositórios oficiais do Debian você pode verificar quais chaves estão instaladas na base de conferência do apt se só tiver as chaves oficiais do Debian fica que é só um mirror e o apt ia xiar que não está assinado por uma chave valida apt key ele lista as chaves que o apt confia e normalmente só vem as chaves oficiais do Debian se só tiver elas ele só vai confiar no repositório oficial e aí no caso seria o mirror da parte de programação de test e tal as imagens são necessárias para poder contribuir a maioria das coisas é impaito mas quando você fala a maioria, não tem muita coisa pronto decidimos se unimos falamos mais ou menos o ideal que a gente queria foi um impaito que a gente começou a fazer como é o processo para mandar uma imagem para um cloud provider eu acho que depende de cada um mas por exemplo, é uma pessoa que envia ela tem um acesso a uma conta e manda para lá exato, esses cloud providers dão uma conta para o Debian então o time de cloud não sei quem tem acesso mas tem uma conta de Debian para cada cloud provider que eles podem entrar lá subir a imagem porque todas elas oferecem um meio de você fazer uma imagem custom e subir ela então tem que seguir esse processo e sobre o agente por exemplo, no caso da Amazon é que eu não sei se quando você fala agente é o agente que eu estou pensando que seria por exemplo o agente do cloud ou de server manager o SSM da Amazon eu não vou saber dizer a gente tem uma imagem do Debian na Amazon hoje certo então eu imagino que seja isso seria ver com o instalado por padrão hoje é possível instalar por fora ou não você pode botar a máquina Debian tem por exemplo, por que se for no caso desse agente, a Amazon fornece uma rede oficial para o Ubuntu e daí seria possível instalar isso você sabe se a imagem do Ubuntu já tem esse agente instalado? eu não sei dizer realmente não sei dizer a parte do Ubuntu o que eu sei é que para a Amazon o que eu acho parece que o da Amazon que é legal é que eles estão usando eu acho que já estão usando os outros softwares que já estão todos no Debian não tem nenhum agente fora eu imagino que ele já vem instalado por default e precisa deles para fazer para utilizar algumas funcionalidades eles devem já vir instalados por default mas eu não sei dizer para você com precisão uma coisa que eu percebo em questão de cloud provider o Ubuntu acaba saindo na frente do Debian não sei por que exatamente mas a impressão que passa é que as imagens deles sempre estão um pouco mais prontas está acontecendo alguma coisa lá que acaba não voltando então eu tive esse feedback lá no sprint e eu descobri que a maioria dos clientes usam Debian a maioria dos clientes deles usam Debian porque geralmente e clientes grandes o feedback que eu tive é quem usa o Ubuntu não tem muita experiência quem usa a Red Hat mais a Red Hat também não tem muita experiência eles dependem do suporte mas quem usa a Debian sabe o que está fazendo então são as grandes empresas as grandes infraestruturas que eles têm um time mesmo eles usam Debian e eu vi que a maioria dos clientes são Debian eu achei isso bem interessante você comentou que tinha representantes dessas empresas no sprint eram pessoas que trabalhavam nas empresas e foram lá para ajudar isso, eram pessoas que faziam parte do time de cada uma das empresas gerar essas imagens para cada uma delas e as pessoas estão tentando se juntar para fazer uma coisa incomum alguém quer falar alguma coisa? mais perguntas eu com certeza tenho mais perguntas mas eu nunca se penso agora às vezes eu estou pensando o que eu vou perguntar eu uso bastante servidores na nuvem mas eu nunca conheci esse lado da distribuição, como é que trabalha as pessoas que ajudam a fazer isso mas eu não lembro agora se eu pensar em uma pergunta pode falar comigo também em qualquer momento e acho que é isso então antes de terminar só queria divulgar essa conferência de novo que a gente vai ter uma conferência que se chama Linux Developer Conference Brasil que vai ser do dia 25 a 26 de agosto em Campinas a ideia dessa conferência é a segunda edição da conferência a ideia da conferência que seja um ponto de encontro internacional de desenvolvedores, entusiasas e indústria então a gente quer alavancar aí a comunidade brasileira para trabalhar upstream de coisas core do Linux seja a internet das coisas sem os embarcados Kern do Linux o Debian e tem vários outros assuntos enfim, essa é uma chamada para participarem eu não escutei, perdão o Linux Developer Conference da ERPI não da ERPI nem conheço tem parecido entendi bom eu acho que não tem se eu entendi direito a pergunta enfim é isso aí, muito obrigada