Repositori OpenTF kini telah dibuka untuk publik

• OpenTofu adalah alat OSS untuk membangun, mengubah, dan mengelola versi infrastruktur secara aman dan efisien
• Dapat mengelola baik penyedia layanan populer yang sudah ada maupun solusi kustom internal
• Menggunakan pendekatan Infrastructure as Code yang mendeskripsikan infrastruktur dengan sintaks konfigurasi tingkat tinggi, sehingga cetak biru pusat data dapat dikelola versinya, dibagikan, dan digunakan ulang seperti kode
• Menyediakan tahap planning yang menghasilkan rencana eksekusi sebelum pemanggilan apply, sehingga Anda dapat melihat lebih dulu tindakan yang akan dilakukan OpenTofu pada infrastruktur
• Membuat Resource Graph untuk semua resource dan memparalelkan pembuatan maupun perubahan resource yang tidak memiliki dependensi, sehingga memberikan visibilitas terhadap dependensi infrastruktur
• Kumpulan perubahan yang kompleks dapat diterapkan dengan intervensi manusia seminimal mungkin, dan melalui rencana eksekusi serta grafik resource, Anda dapat memeriksa apa yang akan diubah dan dalam urutan apa
• Tersedia Nightly Builds untuk menguji perubahan terbaru di main, namun ini adalah build eksperimental dan bukan untuk penggunaan produksi
  • Setiap nightly build akan dihapus setelah 30 hari
  • Informasi build terbaru tersedia di https://nightlies.opentofu.org/nightlies/latest.json
• Kerentanan keamanan atau potensi kerentanan dilaporkan mengikuti Security Policy
• Akses registry dari negara asal tertentu diblokir, dengan rincian mengikuti Registry Inclusion Policy
• Lisensinya adalah Mozilla Public License v2.0

[GN⁺]

Opini Hacker News

• Sesuai banyak permintaan, akhirnya repositori sudah dibuka untuk publik, dan ke depannya pengembangan akan dilanjutkan secara terbuka.
  Memang butuh waktu, tetapi detailnya bisa dilihat di pengumuman: https://opentf.org/fork
  Terima kasih atas dukungannya sejauh ini, dan kami berharap kalian ikut berdiskusi atau berkontribusi di repositori.
  Cara kontribusi yang juga cukup banyak dibahas di HN diputuskan menggunakan DCO: https://developercertificate.org
  Jika ada pertanyaan, saya bisa menjawab. Saya bekerja di Spacelift, dan sampai proyek ini beralih ke kepemimpinan komite, saya menjabat sebagai Technical Lead sementara untuk OpenTF Project.

  • Kalau Anda technical lead proyek OpenTF, saya penasaran bagaimana perubahan seperti ini digabungkan.
    https://github.com/opentffoundation/opentf/pull/36/commits

• Menurut saya seluruh proses ini cukup keren. HashiCorp sangat paham bahwa lisensi melekat pada versi proyek, bukan pada “proyek” itu sendiri, dan memanfaatkannya untuk memaksimalkan pendapatan produk enterprise.
  Komunitas juga tahu bahwa setelah sebuah lisensi ditempelkan pada versi tertentu, itu tidak bisa ditarik kembali, dan bahwa dengan melakukan fork dari titik tempat lisensi itu berlaku lalu membuat “proyek baru” mereka sendiri per versi, mereka bisa tetap mempertahankannya sebagai open source.
  Menarik melihat bagaimana ini akan berkembang, dan sepertinya akan menjadi studi kasus untuk lisensi perangkat lunak di masa depan. Saya menantikan bagaimana OpenTF akan berjalan dalam jangka panjang.

  • Dari sisi dampak komunitas dan responsnya, ini tampaknya paling dekat dengan pemisahan Hudson dan Jenkins. Meski sisi lisensinya berbeda: https://en.wikipedia.org/wiki/Hudson_(software)
    Rasanya Oracle hampir selalu terlibat dalam hal seperti ini, tetapi untuk Terraform ternyata tidak :D
  • Tidak ada alasan untuk membedakan antara “lisensi yang melekat pada versi proyek” dan “lisensi yang melekat pada proyek itu sendiri”. HashiCorp memang berhak mengubah lisensi ke depannya, dan siapa pun juga berhak tetap memakai versi sebelumnya atau melakukan fork. Itulah yang sebenarnya terjadi di sini.
  • Secara historis, menarik juga untuk melihat codebase Hudson/Jenkins.

• Katanya, “kami sedang berkonsultasi dengan beberapa ahli hukum terkait nama, dan karena penggunaan ‘TF’, OpenTF juga mungkin bukan nama final.”
  Menarik bahwa sekadar memasukkan TF dalam nama saja bisa menjadi masalah.
  Sumber: https://github.com/opentffoundation/opentf/issues/273#issuecomment-1706947318

  • Saya jadi tahu bahwa potensi isu di sini adalah wordmark.
    Untuk detailnya, lihat https://en.wikipedia.org/wiki/Wordmark
    Saya pendiri env0 dan ikut memimpin inisiatif OpenTF.
  • Dari awal saya berpikir seharusnya memakai xenoform alih-alih terraform. Misalnya OpenXenoform dan perintah xf.
  • Karena alasan serupa, YP menjadi NIS.
    https://en.wikipedia.org/wiki/Network_Information_Service

• Ada dua hal yang ingin saya minta. Pertama, akan bagus jika disediakan paket registry mandiri untuk modul maupun provider. Yang saya tahu hanya Artifactory, tetapi di lingkungan yang memakai Nexus, saya tidak ingin menjalankan software repositori besar lainnya.
  Kedua masih terkait: akan bagus jika forking modul provider dibuat lebih mudah. Cara sekarang—membangun secara lokal lalu menyalin biner secara manual ke rekan kerja, atau menunggu PR diterima terutama ketika upstream mewajibkan penandatanganan CLA—kurang ideal.

  • Bisa jelaskan lebih lanjut permintaan pertama? Jika yang Anda inginkan adalah biner self-contained untuk menjalankan registry provider/modul pribadi, ada beberapa proyek open source seperti itu, dan kami juga sudah membuat proof of concept untuk mendistribusikan provider melalui registry OCI seperti DockerHub atau GitHub Container Registry.
    Registry OCI cukup cocok untuk use case ini: https://twitter.com/opentforg/status/1696913055576387599
    Proof of concept ini akan segera berlanjut menjadi RFC publik.
    Terkait permintaan kedua, saya penasaran apakah Anda punya alur kerja ideal yang dibayangkan.
    Saya bekerja di Spacelift, dan sampai proyek ini beralih ke kepemimpinan komite, saya menjabat sebagai Technical Lead sementara untuk OpenTF Project.

• Seharusnya namanya “terrafork”.

  • OpenCorp juga sepertinya bisa. Terraform kan hanya satu produk: https://news.ycombinator.com/item?id=37393844

• Bagus dilihat. Saya sedang menunggu https://github.com/opentffoundation/roadmap/issues/8 agar bisa mencobanya.
  Saya bisa membangun dari source, tetapi kalau memungkinkan ingin memakai release build.

• Saya baru melihat sekilas, dan dokumentasinya tampak bagus. Sebagai orang yang pernah sedikit berkutat dengan internal Terraform, ini terlihat seperti peningkatan yang cukup besar bagi developer yang ingin mengerjakan codebase ini.
  Dokumentasi itu memberikan gambaran umum menyeluruh yang bagus untuk memulai. Kerja bagus.

  • Saya tidak yakin persis dokumentasi mana yang dimaksud, tetapi sebagian besar dokumentasi tidak banyak berubah dari repositori asli selain bagian terkait merek dagang.
    Jika dokumentasinya menjadi bagus, kreditnya harus diberikan kepada para developer Terraform Core.
    Saya bekerja di Spacelift, dan sampai proyek ini beralih ke kepemimpinan komite, saya menjabat sebagai Technical Lead sementara untuk OpenTF Project.

• Ini benar-benar hal sampingan, tetapi logonya terlihat cukup janggal di latar gelap karena berwarna biru tua.
  Garis tepi putihnya juga tidak cukup tebal, sehingga ketika bertumpuk dengan latar gelap, pikselnya terlihat menonjol.

  • Memang ini jelas perdebatan desain yang sepele, tetapi logonya juga terlihat seperti logo TensorFlow, jadi sempat saya kira ini adalah kelompok yang memisahkan proyek dari Google.

• Apakah ada yang punya diff tentang bagaimana codebase ini berbeda dibanding commit Terraform terakhir dengan lisensi yang “masih aman untuk terus dipakai”?
  Saya belum begitu memahami apa sebenarnya yang harus diubah karena kontroversi dan perubahan lisensi baru ini.

  • GitHub punya fitur “compare”. Perbedaan antara titik tempat kami melakukan fork dan main saat ini bisa dilihat di sini: https://github.com/opentffoundation/opentf/compare/8a085b427b74ce3829500a59508b77465f1bbef0...a7d8cdd3eeaac968765c6819222606add3720ecf

• Logo di halaman GitHub tampaknya perlu diperbaiki untuk latar gelap. Terutama pada huruf gelap muncul garis tepi terang, yang terlihat seperti alpha bleed dan menyisakan efek bergerigi.