O repositório OpenTF agora está público

 (github.com/opentffoundation)
1 pontos por GN⁺ 2023-09-06 | 1 comentários | Compartilhar no WhatsApp
  • OpenTofu é uma ferramenta OSS para criar, modificar e versionar infraestrutura com segurança e eficiência
  • É possível gerenciar tanto provedores de serviço populares já existentes quanto soluções personalizadas internas
  • Usa a abordagem Infrastructure as Code, que descreve a infraestrutura com uma sintaxe de configuração de alto nível, permitindo versionar, compartilhar e reutilizar o blueprint de um datacenter como se fosse código
  • Oferece uma etapa de planning que gera um plano de execução antes de chamar apply, permitindo verificar antecipadamente quais ações o OpenTofu realizará na infraestrutura
  • Cria um Resource Graph de todos os recursos e paraleliza a criação e modificação de recursos sem dependências, oferecendo visibilidade sobre as dependências da infraestrutura
  • Permite aplicar conjuntos complexos de mudanças com o mínimo de intervenção humana, e o plano de execução junto com o grafo de recursos mostra o que será alterado e em que ordem
  • São fornecidos Nightly Builds para testar as mudanças mais recentes da main, mas são builds experimentais e não destinadas a uso em produção
  • Vulnerabilidades de segurança ou potenciais vulnerabilidades devem ser reportadas conforme a Security Policy
  • O acesso ao registro de determinados países de origem é bloqueado, conforme os detalhes da Registry Inclusion Policy
  • A licença é a Mozilla Public License v2.0

Leituras relacionadas

1 comentários

 
GN⁺ 2023-09-06
Opiniões no Hacker News

  • Conforme muito solicitado, finalmente abrimos o repositório e, daqui para frente, pretendemos continuar o desenvolvimento publicamente.
    Demorou um pouco, mas os detalhes estão no anúncio: https://opentf.org/fork
    Agradecemos pelo apoio até agora e esperamos que vocês participem das discussões no repositório ou contribuam.
    O modelo de contribuição, que também foi bastante discutido no HN, foi definido como DCO: https://developercertificate.org
    Se houver perguntas, posso responder. Trabalho na Spacelift e, até que o projeto passe a ser liderado por um comitê, estou atuando como Technical Lead interino do OpenTF Project.

  • Acho esse processo todo bem interessante. A HashiCorp sabia muito bem que a licença se aplica não ao “projeto” em si, mas a uma versão do projeto, e usou isso para maximizar a receita de seus produtos empresariais.
    A comunidade também sabia que, depois que uma licença é atribuída a uma versão específica, isso não pode ser revertido, e que, a partir do ponto em que aquela licença se aplica, bastava fazer um fork para criar seu próprio “novo” projeto por versão e mantê-lo open source.
    Vai ser interessante ver como isso se desenrola, e parece que será um estudo de caso para licenciamento de software no futuro. Estou curioso para ver o que acontecerá com o OpenTF no longo prazo.

    • Em termos de impacto na comunidade e reação, parece mais próximo da separação entre Hudson e Jenkins. A parte de licença é diferente, porém: https://en.wikipedia.org/wiki/Hudson_(software)
      Tenho a impressão de que a Oracle quase sempre está envolvida nessas coisas, mas, no caso do Terraform, surpreendentemente não estava :D
    • Não há motivo para diferenciar “licença aplicada a uma versão do projeto” de “licença aplicada ao projeto em si”. A HashiCorp tinha o direito de alterar a licença futura, e qualquer pessoa também tinha o direito de continuar usando ou fazer fork de versões anteriores. Na prática, foi isso que aconteceu aqui.
    • Historicamente, também pode ser interessante analisar a base de código Hudson/Jenkins.

  • Dizem que “estão consultando alguns especialistas jurídicos em relação ao nome, e, por causa do uso de ‘TF’, OpenTF também pode não ser o nome final”.
    É interessante que apenas ter TF no nome já possa ser um problema.
    Fonte: https://github.com/opentffoundation/opentf/issues/273#issuecomment-1706947318

  • Gostaria de pedir duas coisas. Primeiro, seria bom oferecer um pacote de registro standalone tanto para módulos quanto para providers. O único que conheço é o Artifactory, mas em ambientes que usam Nexus eu não gostaria de rodar mais um grande software de repositório.
    A segunda é relacionada: seria bom facilitar o fork de módulos de providers. Não gosto do fluxo atual de compilar localmente e copiar manualmente o binário para colegas, ou esperar que um PR seja aceito, especialmente quando o upstream exige assinatura de CLA.

    • Você poderia explicar um pouco melhor o primeiro pedido? Se o que você quer é um binário autocontido para rodar um registro privado de providers/módulos, existem alguns projetos open source assim, e também fizemos uma prova de conceito de distribuição de providers via registros OCI como DockerHub ou GitHub Container Registry.
      Registros OCI se encaixam muito bem nesse caso de uso: https://twitter.com/opentforg/status/1696913055576387599
      Essa prova de conceito deve virar uma RFC pública em breve.
      Quanto ao segundo pedido, tenho curiosidade sobre qual seria o fluxo de trabalho ideal que você tem em mente.
      Trabalho na Spacelift e, até que o projeto passe a ser liderado por um comitê, estou atuando como Technical Lead interino do OpenTF Project.

  • Deveriam ter escolhido “terrafork”.

  • Muito bom. Estou aguardando https://github.com/opentffoundation/roadmap/issues/8 para poder testar.
    Consigo compilar a partir do código-fonte, mas, se possível, quero usar um build de release.

  • Dei uma olhada por alto e a documentação parece excelente. Como alguém que já mexeu um pouco na estrutura interna do Terraform, isso parece uma melhoria bem grande para desenvolvedores que queiram trabalhar nessa base de código.
    Ela fornece uma visão geral completa que é um bom ponto de partida. Bom trabalho.

    • Não sei exatamente a qual documentação você se refere, mas a maior parte da documentação não mudou muito em relação ao repositório original, exceto pelas partes relacionadas a marcas.
      Se a documentação ficou boa, o mérito é dos desenvolvedores do Terraform Core.
      Trabalho na Spacelift e, até que o projeto passe a ser liderado por um comitê, estou atuando como Technical Lead interino do OpenTF Project.

  • Totalmente tangencial, mas o logo em azul escuro em um fundo escuro parece bem estranho.
    O contorno branco também não é grosso o suficiente, então, quando se sobrepõe ao fundo escuro, os pixels ficam muito aparentes.

    • Definitivamente é uma discussão de design menor, mas ele também parece o logo do TensorFlow, então por um momento achei que fosse um grupo separando o projeto do Google.

  • Alguém tem um diff de como essa base de código difere do último commit do Terraform com a licença “ainda ok de usar”?
    Não entendo bem o que precisou ser mudado de fato por causa da controvérsia da nova licença e das alterações.

  • O logo na página do GitHub parece precisar de melhorias em fundo escuro. Em particular, surge um contorno claro ao redor das letras escuras, que parece vazamento de alfa e deixa serrilhado.