Le dépôt OpenTF est désormais public

 (github.com/opentffoundation)
1 points par GN⁺ 2023-09-06 | 1 commentaires | Partager sur WhatsApp
  • OpenTofu est un outil OSS destiné à construire, modifier et gérer en version les infrastructures de manière sûre et efficace
  • Il permet de gérer à la fois des fournisseurs de services populaires existants et des solutions personnalisées en interne
  • Il utilise l’approche Infrastructure as Code, qui décrit l’infrastructure avec une syntaxe de configuration de haut niveau, permettant de gérer en version, partager et réutiliser les plans de datacenter comme du code
  • Il fournit une étape de planning qui génère un plan d’exécution avant l’appel à apply, afin de vérifier à l’avance quelles opérations OpenTofu effectuera sur l’infrastructure
  • Il crée un Resource Graph de toutes les ressources et parallélise la création et la modification des ressources sans dépendances, offrant une visibilité sur les dépendances de l’infrastructure
  • Il permet d’appliquer des ensembles de changements complexes avec un minimum d’intervention humaine, et le plan d’exécution ainsi que le graphe des ressources permettent de voir ce qui sera modifié et dans quel ordre
  • Des Nightly Builds sont proposées pour tester les derniers changements de main, mais ce sont des builds expérimentaux qui ne sont pas destinés à un usage en production
  • Les vulnérabilités de sécurité ou vulnérabilités potentielles doivent être signalées conformément à la Security Policy
  • L’accès au registre est bloqué pour certains pays d’origine, conformément aux détails de la Registry Inclusion Policy
  • La licence est la Mozilla Public License v2.0

À lire aussi

1 commentaires

 
GN⁺ 2023-09-06
Avis sur Hacker News

  • Comme beaucoup l’avaient demandé, le dépôt est enfin public, et le développement se poursuivra désormais ouvertement.
    Cela a pris un peu de temps, mais les détails sont dans l’annonce : https://opentf.org/fork
    Merci pour tout le soutien jusqu’ici ; n’hésitez pas à participer aux discussions dans le dépôt ou à contribuer.
    Le mode de contribution, qui avait aussi été pas mal discuté sur HN, sera le DCO : https://developercertificate.org
    S’il y a des questions, je peux y répondre. Je travaille chez Spacelift et je suis Technical Lead intérimaire du projet OpenTF jusqu’à ce qu’il passe sous la direction du comité.

  • Je trouve tout ce processus assez intéressant. HashiCorp savait très bien que la licence ne s’applique pas au “projet” lui-même, mais à une version du projet, et s’en est servi pour maximiser les revenus de ses produits d’entreprise.
    La communauté savait aussi qu’une fois une licence attachée à une version donnée, on ne peut pas revenir en arrière, et qu’en forkant à partir du point où cette licence s’appliquait, puis en créant son propre “nouveau” projet version par version, il était possible de le maintenir en open source.
    Ce sera intéressant de voir la suite, et cela pourrait devenir une étude de cas pour les futures licences logicielles. J’ai hâte de voir ce qu’OpenTF deviendra à long terme.

    • En matière d’impact sur la communauté et de réaction, cela ressemble surtout à la séparation entre Hudson et Jenkins. Côté licence, c’est différent : https://en.wikipedia.org/wiki/Hudson_(software)
      J’ai l’impression qu’Oracle est presque toujours impliqué dans ce genre d’affaires, mais étonnamment pas avec Terraform :D
    • Il n’y a pas de raison de distinguer une “licence attachée à une version du projet” d’une “licence attachée au projet lui-même”. HashiCorp avait le droit de changer la licence pour l’avenir, et tout le monde avait le droit de continuer à utiliser ou de forker les versions précédentes. C’est exactement ce qui s’est passé ici.
    • Historiquement, il pourrait aussi être intéressant de regarder la base de code Hudson/Jenkins.

  • Il est indiqué qu’ils “consultent plusieurs juristes au sujet du nom, et qu’à cause de l’utilisation de ‘TF’, OpenTF pourrait ne pas être le nom définitif”.
    C’est intéressant de voir que le simple fait d’avoir TF dans le nom peut poser problème.
    Source : https://github.com/opentffoundation/opentf/issues/273#issuecomment-1706947318

  • J’aimerais demander deux choses. Premièrement, ce serait bien de proposer un paquet de registre autonome pour les modules comme pour les fournisseurs. Le seul que je connaisse est Artifactory, mais dans un environnement qui utilise Nexus, je n’ai pas envie de faire tourner un autre gros logiciel de dépôt.
    La deuxième demande est liée : ce serait bien de faciliter le fork des modules de fournisseurs. La situation actuelle, où l’on compile localement puis distribue les binaires aux collègues par copie manuelle, ou bien où l’on attend que la PR soit acceptée, surtout lorsque l’upstream exige de signer un CLA, n’est pas idéale.

    • Peux-tu préciser un peu la première demande ? Si tu veux un binaire autonome permettant de faire tourner un registre privé de fournisseurs/modules, il existe quelques projets open source de ce type, et nous avons aussi réalisé une preuve de concept pour distribuer des fournisseurs via des registres OCI comme DockerHub ou GitHub Container Registry.
      Les registres OCI conviennent assez bien à ce cas d’usage : https://twitter.com/opentforg/status/1696913055576387599
      Cette preuve de concept devrait bientôt donner lieu à une RFC publique.
      Pour la deuxième demande, je serais curieux de savoir quel workflow idéal tu imagines.
      Je travaille chez Spacelift et je suis Technical Lead intérimaire du projet OpenTF jusqu’à ce qu’il passe sous la direction du comité.

  • Il aurait fallu l’appeler “terrafork”.

  • Bonne nouvelle. J’attends https://github.com/opentffoundation/roadmap/issues/8 pour pouvoir tester.
    Je peux compiler depuis les sources, mais si possible j’aimerais utiliser un build de release.

  • J’ai parcouru rapidement, et la documentation a l’air excellente. Pour avoir un peu travaillé avec les entrailles de Terraform, cela me semble être une nette amélioration pour les développeurs qui veulent travailler sur cette base de code.
    Elle fournit une vue d’ensemble très utile pour démarrer. Beau travail.

    • Je ne sais pas exactement de quelle documentation tu parles, mais la plupart des documents n’ont pas beaucoup changé par rapport au dépôt d’origine, à part les éléments liés aux marques.
      Si la documentation s’est améliorée, le mérite revient aux développeurs de Terraform Core.
      Je travaille chez Spacelift et je suis Technical Lead intérimaire du projet OpenTF jusqu’à ce qu’il passe sous la direction du comité.

  • C’est complètement secondaire, mais le logo est en bleu foncé sur fond sombre, ce qui rend assez bizarre.
    Le contour blanc n’est pas assez épais non plus, et lorsqu’il se superpose au fond sombre, les pixels ressortent beaucoup.

    • C’est clairement une querelle de design mineure, mais il ressemble aussi au logo de TensorFlow, au point que j’ai cru un instant qu’il s’agissait d’un groupe visant à rendre le projet indépendant de Google.

  • Quelqu’un a-t-il un diff montrant en quoi cette base de code diffère du dernier commit de Terraform sous licence “encore acceptable à utiliser” ?
    Avec la polémique autour de la nouvelle licence et les changements, je ne comprends pas bien ce qu’il a réellement fallu modifier.

  • Le logo sur la page GitHub semble avoir besoin d’améliorations sur fond sombre. Il y a notamment un contour clair autour des lettres sombres, qui ressemble à un débordement alpha et laisse un effet d’escalier.