Das OpenTF-Repository ist jetzt öffentlich

 (github.com/opentffoundation)
1 Punkte von GN⁺ 2023-09-06 | 1 Kommentare | Auf WhatsApp teilen
  • OpenTofu ist ein OSS-Tool, um Infrastruktur sicher und effizient aufzubauen, zu ändern und zu versionieren
  • Es kann sowohl bestehende beliebte Service-Provider als auch unternehmensinterne maßgeschneiderte Lösungen verwalten
  • Es nutzt den Ansatz Infrastructure as Code, bei dem Infrastruktur in einer Konfigurationssprache auf hohem Niveau beschrieben wird, sodass Rechenzentrums-Blueprints wie Code versioniert, geteilt und wiederverwendet werden können
  • Vor dem Aufruf von apply gibt es einen Planning-Schritt, der einen Ausführungsplan erstellt, damit sich vorab prüfen lässt, welche Arbeiten OpenTofu an der Infrastruktur durchführen wird
  • Es erstellt einen Resource Graph aller Ressourcen und parallelisiert die Erstellung und Änderung von Ressourcen ohne Abhängigkeiten, wodurch Transparenz über Infrastrukturabhängigkeiten entsteht
  • Komplexe Änderungssätze können mit minimalem menschlichem Eingriff angewendet werden, und über Ausführungsplan und Ressourcen-Graph lässt sich prüfen, was in welcher Reihenfolge geändert wird
  • Es werden Nightly Builds bereitgestellt, um die neuesten Änderungen an main zu testen; es handelt sich um experimentelle Builds und sie sind nicht für den Einsatz in der Produktion gedacht
  • Sicherheitslücken oder potenzielle Schwachstellen sollen gemäß der Security Policy gemeldet werden
  • Der Zugriff auf die Registry aus bestimmten Herkunftsländern wird blockiert; Details dazu stehen in der Registry Inclusion Policy
  • Die Lizenz ist die Mozilla Public License v2.0

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-09-06
Hacker-News-Kommentare

  • Wie vielfach gewünscht, haben wir das Repository endlich öffentlich gemacht und werden die Entwicklung künftig öffentlich fortführen.
    Es hat etwas gedauert, aber die Details stehen in der Ankündigung: https://opentf.org/fork
    Danke für die bisherige Unterstützung; wir hoffen, dass ihr euch im Repository an Diskussionen beteiligt oder Beiträge leistet.
    Als Beitragsmodell, das auch auf HN ausführlich diskutiert wurde, haben wir uns für DCO entschieden: https://developercertificate.org
    Wenn es Fragen gibt, kann ich sie beantworten. Ich arbeite bei Spacelift und bin bis zur Übergabe an die Leitung durch das Komitee der Interims-Technical-Lead des OpenTF Project.

  • Ich finde diesen ganzen Vorgang ziemlich spannend. HashiCorp wusste genau, dass eine Lizenz nicht am „Projekt“ selbst hängt, sondern an einer Projektversion, und hat das genutzt, um die Einnahmen aus dem Enterprise-Produkt zu maximieren.
    Die Community wusste ebenfalls, dass eine einmal an eine bestimmte Version geknüpfte Lizenz nicht rückgängig gemacht werden kann, und dass man ab dem Punkt, an dem diese Lizenz gilt, forken und pro Version ein eigenes „neues“ Projekt schaffen kann, um weiter Open Source zu bleiben.
    Ich bin gespannt, wie sich das entwickelt; das dürfte künftig eine Fallstudie für Softwarelizenzen werden. Ich bin neugierig, was langfristig aus OpenTF wird.

    • In Bezug auf Community-Auswirkungen und Reaktion wirkt es am ehesten wie die Abspaltung von Hudson und Jenkins. Die Lizenzseite ist allerdings anders: https://en.wikipedia.org/wiki/Hudson_(software)
      Gefühlt ist Oracle bei solchen Dingen fast immer irgendwie beteiligt, bei Terraform überraschenderweise aber nicht :D
    • Es gibt keinen Grund, zwischen einer „Lizenz, die an einer Projektversion hängt“ und einer „Lizenz, die am Projekt selbst hängt“ zu unterscheiden. HashiCorp hatte das Recht, die Lizenz für die Zukunft zu ändern, und jeder hatte das Recht, ältere Versionen weiter zu nutzen oder zu forken. Genau das ist hier passiert.
    • Historisch könnte es auch interessant sein, sich die Hudson/Jenkins-Codebasis anzusehen.

  • Es heißt: „Wir beraten uns wegen des Namens mit einigen Rechtsexperten, und wegen der Verwendung von ‚TF‘ ist möglicherweise auch OpenTF nicht der endgültige Name.“
    Interessant, dass allein TF im Namen schon ein Problem sein könnte.
    Quelle: https://github.com/opentffoundation/opentf/issues/273#issuecomment-1706947318

  • Ich hätte zwei Wünsche. Erstens wäre ein Standalone-Registry-Paket sowohl für Module als auch für Provider schön. Das Einzige, das ich kenne, ist Artifactory, aber in einer Umgebung mit Nexus möchte ich nicht noch eine große Repository-Software betreiben.
    Der zweite Punkt hängt damit zusammen: Es sollte einfacher werden, Provider-Module zu forken. Die heutige Arbeitsweise, lokal zu bauen und Binärdateien manuell an Kollegen zu verteilen, oder darauf zu warten, dass ein PR akzeptiert wird, insbesondere wenn Upstream die Unterzeichnung eines CLA verlangt, ist nicht besonders gut.

    • Kannst du den ersten Wunsch etwas genauer erklären? Wenn du ein in sich geschlossenes Binary meinst, mit dem man eine private Provider-/Modul-Registry betreiben kann: Es gibt ein paar solche Open-Source-Projekte, und wir haben auch einen Proof of Concept für die Verteilung von Providern über OCI-Registries wie DockerHub oder GitHub Container Registry ausprobiert.
      OCI-Registries passen ziemlich gut zu diesem Use Case: https://twitter.com/opentforg/status/1696913055576387599
      Aus diesem Proof of Concept wird bald ein öffentlicher RFC entstehen.
      Zum zweiten Wunsch: Mich würde interessieren, welchen idealen Workflow du dir vorstellst.
      Ich arbeite bei Spacelift und bin bis zur Übergabe an die Leitung durch das Komitee der Interims-Technical-Lead des OpenTF Project.

  • Man hätte es „terrafork“ nennen sollen.

  • Sieht gut aus. Ich warte auf https://github.com/opentffoundation/roadmap/issues/8, um es testen zu können.
    Ich kann zwar aus dem Source bauen, würde aber nach Möglichkeit lieber Release-Builds verwenden.

  • Ich habe es nur grob überflogen, aber die Dokumentation sieht hervorragend aus. Als jemand, der sich schon etwas mit den Terraform-Interna beschäftigt hat, wirkt das wie eine ziemlich große Verbesserung für Entwickler, die an dieser Codebasis arbeiten wollen.
    Sie liefert einen guten Gesamtüberblick für den Einstieg. Gut gemacht.

    • Ich bin nicht ganz sicher, welche Dokumentation du meinst, aber die meisten Dokumente wurden gegenüber dem ursprünglichen Repository abgesehen von markenrechtlichen Stellen kaum verändert.
      Wenn die Dokumentation gut geworden ist, gebührt der Verdienst den Terraform-Core-Entwicklern.
      Ich arbeite bei Spacelift und bin bis zur Übergabe an die Leitung durch das Komitee der Interims-Technical-Lead des OpenTF Project.

  • Völlig nebensächlich, aber das Logo sieht auf dunklem Hintergrund mit dem dunklen Blau ziemlich seltsam aus.
    Auch die weiße Kontur ist nicht dick genug, sodass bei Überlagerung mit dunklem Hintergrund die Pixel stark auffallen.

    • Sicher eine Kleinigkeit aus der Design-Ecke, aber es sieht auch ein bisschen aus wie das TensorFlow-Logo, sodass ich kurz dachte, es handle sich um eine Gruppe, die das Projekt von Google abspaltet.

  • Hat jemand ein Diff, wie sich diese Codebasis gegenüber dem letzten Terraform-Lizenz-Commit unterscheidet, den man „weiterhin bedenkenlos nutzen“ kann?
    Ich verstehe nicht so recht, was wegen der neuen Lizenzkontroverse und der Änderungen tatsächlich geändert werden musste.

  • Das Logo auf der GitHub-Seite wirkt auf dunklem Hintergrund verbesserungsbedürftig. Insbesondere bekommen die dunklen Buchstaben eine helle Kontur, die wie Alpha-Bleeding aussieht, und es bleibt Treppchenbildung zurück.