Toolbox: mesclar com coretoolbox, ou não

Discutimos isso na reunião do Fedora CoreOS hoje .

  * AGREED: regarding golang vs rust that is up to the author of
    toolbox. we do care about size and exploding the number of
    container-runtime implementations. If Golang is chosen we prefer
    that we don't vendor libpod, but rather either shell out or use the
    varlink API to manage containers.  (dustymabe, 17:33:38)

então @debarshiray @cgwalters é suficiente dizer os tópicos a serem investigados:

1. o projeto debarshiray/toolbox ficará bem em não vender libpod (ou seja, desembolsar ou usar varlink) para não aumentar o tamanho da caixa de ferramentas?
2. se pudermos obter consenso no ponto 1, então @cgwalters você concorda que ferrugem ou golang são ferramentas suficientes (desconsiderando "preferências" pessoais)

se pudermos obter consenso no ponto 1, então @cgwalters você concorda que ferrugem ou golang são ferramentas suficientes (desconsiderando "preferências" pessoais)

Sim claro.

1. will the debarshiray/toolbox project be ok with not vendoring libpod

(ou seja, desembolsar ou usar varlink) para não explodir o tamanho da caixa de ferramentas?

Fico feliz em desembolsar o Podman de um binário de wrapper Go, já que o tamanho inflado da venda em libpod é um fator decisivo para o CoreOS.

Fico feliz em desembolsar o Podman a partir de um binário de wrapper Go, já que o tamanho inflado da venda no libpod é um fator decisivo para o CoreOS.

Se estamos reescrevendo, por que não usar minha implementação Rust existente? Esse é um ponto importante nisso - eu já tenho código de trabalho que uso ativamente.

Um bom ponto para Rust BTW é que o material varlink upstream tem muito código Rust ótimo. Dito isso, o varlink-go também existe.

Se estamos reescrevendo, por que não usar minha implementação Rust existente? Esse é um ponto importante nisso - eu já tenho código de trabalho que uso ativamente.

Para detalhar melhor, aqui está uma proposta - movemos debarshiray/toolbox para coreos/toolbox e, em seguida, temos um commit que substitui a maior parte do código por cgwalters/coretoolbox - @debarshiray se torna um co-mantenedor junto com outros do grupo CoreOS. (Ou podemos mudar para fedora-silverblue/ GH org, já que atualmente está mais associado a isso, mas também queremos capturar os casos raiz do host, que é mais coreos/)

Estou farto desse tom agressivo passivo constante tentando empurrar o coretoolbox em todos os lugares, e comportamento que se parece muito com tentar assumir o controle deste projeto.

Por favor pare!

Dadas quantas vezes falamos sobre isso no passado recente, e seu comportamento estranhamente evasivo e agressivo, não posso mais presumir bem.

O projeto Toolbox existe porque Silverblue precisava absolutamente de uma maneira de oferecer aos desenvolvedores a configuração de seu próprio ambiente de desenvolvimento. Alguns de nós trabalhando no Silverblue, com muita ajuda da equipe do Podman, hackeamos algo usando o Podman sem raiz que nos deu o que precisávamos. Uma grande parte desse esforço foi apenas para fazer o Podman sem root funcionar, porque não podemos dizer aos usuários do Silverblue que eles agora precisam ser root para obter um shell.

Você provavelmente não está ciente da realidade porque o coretoolbox apareceu apenas em abril de 2019. Naquela época, muitas grandes turbulências haviam diminuído. No entanto, no verão de 2018, quando o Podman sem raízes mal existia, as coisas estavam muito tempestuosas.

Diga o que quiser sobre scripts de shell, é incrivelmente fácil compartilhar um script e esperar que a outra parte possa ajustá-lo e executá-lo; e quando seu fluxo de trabalho de desenvolvimento envolve principalmente lançar encantamentos aleatórios do Podman e ver o que funciona e o que não funciona e por que não, essa facilidade é absolutamente crítica para fazer qualquer progresso. Não há como você pedir a uma pessoa aleatória para pegar um pouco de Rust ou Go ou qualquer outro código e esperar que eles experimentem em questão de minutos. Muitos provavelmente se recusam a não saber como construí-lo, e você pode esquecer de chegar ao ponto de segurá-los na versão correta do Podman ou em alguma correção de configuração ou qualquer outra coisa.

Também vou salientar que nunca vi nenhum feedback real da equipe CoreOS. Nunca.

Ao longo do ano passado, estive em várias reuniões de IRC, conversei com várias pessoas na vida real, e tudo o que ouvi é basicamente sim, sim, adoramos o Toolbox, vamos enviar patches para fazê-lo funcionar no CoreOS . Exceto, eu não vi um único patch.

O primeiro feedback real foi no dia 8 de julho deste ano sobre as dependências infladas sendo puxadas pelo RPM da caixa de ferramentas, que eu persegui e consertei.

Enquanto isso, a equipe Silverblue tem estado ocupada continuamente acompanhando o desenvolvimento do Podman, testando as versões do Podman em todas as ramificações suportadas, trabalhando para melhorar os testes automatizados, trabalhando em uma migração difícil após a outra... A lista continua.

Você acha que tem código de trabalho? Você tem documentação? Você tem testes ?

Ah, e quantos usuários você tem? Quantos usuários selvagens você já segurou para descobrir por que algum contêiner antigo não está mais funcionando com novas ferramentas? Quantas regressões você rastreou para cima e para baixo na pilha do GNOME para o tempo de execução da OCI?

Temos muitos usuários finais reais usando o Toolbox em estado selvagem. Não podemos simplesmente levantar e sair, e de repente mudar tudo. Temos uma tonelada de bugs do Cgroups v2 que precisam ser resolvidos com urgência para o Fedora 31 .

Você se pergunta por que o Toolbox ainda está escrito no shell POSIX? Aqui está a sua resposta - estivemos ocupados.

Os usuários do Silverblue geralmente não esperam ter que saber como seu sistema operacional funciona ou os detalhes da tecnologia de contêiner. Eles esperam executar toolbox enter e obter um shell. Eles não recebem uma concha, eles jogam as mãos para cima e reclamam.

Cada obstáculo aleatório no uso do Silverblue, comparado ao legado Workstation, é um obstáculo à adoção.

Você acha que sabe o quão crítico é o Toolbox? Confie em mim, nós sabemos. Para Silverblue, o Toolbox é quase tão crítico quanto o Bash.

Também nunca vi uma lista concreta de especificações do CoreOS. Não é à toa que https://github.com/coreos/fedora-coreos-tracker/issues/38 serpenteia de um detalhe para outro sem nunca especificar quais são os requisitos rígidos.

Compare isso com https://fedoraproject.org/wiki/Workstation/Desktop_Containers

Acho que está bem claro o quão crucial o Toolbox é para o Silverblue, possivelmente muito mais do que o CoreOS, porque, no final das contas, aparecemos para fazer todo o trabalho pesado.

Poderíamos facilmente ter levado o Toolbox em uma direção que é fundamentalmente problemática para o CoreOS, como escrevê-lo em Go com libpod ou qualquer outra coisa, mas não fizemos, não é? Mesmo quando tudo o que você podia fazer era fanboy de Rust sem nunca especificar quais são suas necessidades reais.

Também absorvemos várias ideias interessantes do coretoolbox com atribuição total sem que você precise levantar um único dedo.

Que tal aprender a mostrar um pouco de gratidão e agradecer primeiro?

Quanto à direção futura do Toolbox...

A caixa de ferramentas será reescrita em Go. É a linguagem em que o resto do ecossistema OCI, incluindo o Podman, está escrito. Não existe tal coisa como trabalhar no Toolbox sem tocar na pilha do Podman. É do nosso interesse ficar o mais alinhado possível. Seria um obstáculo desnecessário dizer aos colaboradores que eles precisam ser alfabetizados em Rust e Go para trabalhar no Toolbox.

Não queremos usar Varlink, se pudermos evitá-lo. Não é algo que usamos atualmente no Silverblue, a equipe Podman não está muito feliz com isso e, independentemente, seria arriscado colocar uma tecnologia fundamentalmente nova no meio de algo tão crucial. Prefiro concentrar nossos esforços em tornar o Podman o mais robusto possível.

Quanto à venda de libpod versus desembolsar $ podman , vamos nos ater ao último, como discutimos na reunião do CoreOS, para manter /usr/bin/toolbox o menor possível.

Pessoalmente, ficaria feliz em ver o CoreOS usar o Toolbox e continuarei ouvindo e atendendo às necessidades do CoreOS o máximo possível. Claro, contribuições são bem-vindas e tudo mais. Também não vou invejar você se o CoreOS decidir não usar o Toolbox por qualquer motivo.

No entanto, não vou mover este projeto para outro lugar por algum motivo vago e indeciso, ou apenas porque alguém na Internet descobriu que o Podman sem raízes é uma coisa. Aqueles que aparecem todos os dias para lidar com toda a dificuldade chata decidem.

Fechando.

Que tal aprender a mostrar um pouco de gratidão e agradecer primeiro?

Obrigado!

Dadas quantas vezes falamos sobre isso no passado recente, e seu comportamento estranhamente evasivo e agressivo, não posso mais presumir bem.

Hum, vamos mudar isso! Não sei o que é evasivo. Lamento que perceba a agressão. Eu certamente tenho opiniões técnicas fortes, mas por favor, não leve nada para o lado pessoal. Mais importante; a razão pela qual continuo a ter conversas como esta é porque quero trabalhar juntos!

Estou farto desse tom agressivo passivo constante tentando empurrar o coretoolbox em todos os lugares, e comportamento que se parece muito com tentar assumir o controle deste projeto.

Ah, mas - estamos falando de algo muito importante aqui. Eu absolutamente aprecio todo o trabalho que você fez. Mas temos divergências técnicas.

Deixe-me dizer claramente: eu pessoalmente quero mais controle sobre a direção futura deste projeto. Isso não é o mesmo que controle total. Eu acredito em "consenso bruto e código de trabalho". Acho que podemos trabalhar juntos! Você e eu nos conhecemos, espero que concorde.

Como você sabe, o coretoolbox começou porque tentei contribuir com um patch e ele não foi mesclado. Então vamos manter isso em mente! Eu tentei hackear o script de shell primeiro.

Ah, e quantos usuários você tem?

Ah, não muitos. Mas, há, por exemplo, este comentário .

Mesmo quando tudo o que você podia fazer era fanboy de Rust sem nunca especificar quais são suas necessidades reais.

Hmm, agora isso é simplesmente desnecessário. Já falamos sobre as razões para usar uma linguagem real, como análise de opções, arquivos de configuração, tratamento de erros, etc. Dito isso, eu também amo Rust, é verdade :wink:

No entanto, não vou mover este projeto para outro lugar por algum motivo vago e indeciso, ou apenas porque alguém na Internet descobriu que o Podman sem raízes é uma coisa. Aqueles que aparecem todos os dias para lidar com toda a dificuldade chata decidem.

Aqui está outra maneira de olhar para isso - novamente, dada a criticidade, acho que o projeto deve passar para uma manutenção que não seja apenas você e seu domínio pessoal do github. Eu absolutamente quero contribuir para tal projeto.

A caixa de ferramentas será reescrita em Go. É a linguagem em que o resto do ecossistema OCI, incluindo o Podman, está escrito. Não existe tal coisa como trabalhar no Toolbox sem tocar na pilha do Podman. É do nosso interesse ficar o mais alinhado possível. Seria um obstáculo desnecessário dizer aos colaboradores que eles precisam ser alfabetizados em Rust e Go para trabalhar no Toolbox.

Então, obviamente, é aqui que ficamos presos - mas acho que o problema do idioma deve vir após a manutenção. Você vê este projeto permanecendo em seu GH pessoal sob sua exclusiva responsabilidade, ou você o vê se movendo para, por exemplo, o coreos/GH org ou fedora-silverblue/GH org e tendo vários mantenedores?

Qual é a melhor maneira de executar a caixa de ferramentas no FCOS aws ami (v31.20200223.3.0)?

Eu tentei executar a caixa de ferramentas, mas não está funcionando

toolbox create
toolbox: TOOLBOX_PATH not set

TOOLBOX_PATH=/usr/bin/toolbox toolbox create
toolbox: this is not a toolbox container