OpenTF रिपॉज़िटरी अब सार्वजनिक हो गई है

• OpenTofu इंफ्रास्ट्रक्चर को सुरक्षित और कुशल तरीके से बनाना, बदलना और version control करने के लिए एक OSS टूल है
• यह मौजूदा लोकप्रिय service providers और इन-हाउस कस्टम solutions दोनों को मैनेज कर सकता है
• यह Infrastructure as Code तरीके का उपयोग करता है, जिसमें इंफ्रास्ट्रक्चर को high-level configuration syntax में परिभाषित किया जाता है, और data center blueprints को कोड की तरह version control, share और reuse किया जा सकता है
• apply कॉल से पहले execution plan बनाने वाला planning चरण देता है, जिससे OpenTofu इंफ्रास्ट्रक्चर पर क्या काम करेगा, यह पहले से देखा जा सकता है
• यह सभी resources का Resource Graph बनाता है और जिन resources में dependency नहीं है, उनकी creation और modification को parallelize करके इंफ्रास्ट्रक्चर dependencies पर visibility देता है
• यह कम से कम human intervention के साथ जटिल change sets लागू कर सकता है, और execution plan तथा resource graph के जरिए यह देखा जा सकता है कि क्या और किस क्रम में बदला जाएगा
• main के नवीनतम बदलावों को टेस्ट करने के लिए Nightly Builds उपलब्ध हैं, लेकिन ये experimental builds हैं और production उपयोग के लिए नहीं हैं
  • हर nightly build 30 दिनों बाद हटा दी जाती है
  • नवीनतम build जानकारी https://nightlies.opentofu.org/nightlies/latest.json पर उपलब्ध है
• सुरक्षा कमजोरियों या संभावित कमजोरियों की रिपोर्ट Security Policy के अनुसार की जानी चाहिए
• कुछ विशेष मूल-देशों की registries तक पहुंच रोकी जाती है, और विवरण Registry Inclusion Policy के अनुसार हैं
• लाइसेंस Mozilla Public License v2.0 है

[GN⁺]

Hacker News टिप्पणियाँ

• जैसा कई लोगों ने अनुरोध किया था, आखिरकार हमने repository को public कर दिया है, और आगे development public तरीके से जारी रहेगा
  इसमें थोड़ा समय लगा, लेकिन अधिक जानकारी announcement में देखी जा सकती है: https://opentf.org/fork
  अब तक के support के लिए धन्यवाद, और उम्मीद है कि आप repository में चर्चा में शामिल होंगे या contribute करेंगे
  HN पर भी काफी चर्चा हुई contribution method के लिए हमने DCO चुना है: https://developercertificate.org
  अगर सवाल हों तो मैं जवाब दे सकता हूँ। मैं Spacelift में काम करता हूँ, और committee-led model में जाने तक OpenTF Project का interim Technical Lead हूँ

  • अगर आप OpenTF project के technical lead हैं, तो यह जानना चाहूँगा कि ऐसे बदलाव merge कैसे होते हैं
    https://github.com/opentffoundation/opentf/pull/36/commits

• मुझे यह पूरी प्रक्रिया काफी शानदार लगती है। HashiCorp अच्छी तरह जानता था कि license “project” खुद पर नहीं, बल्कि project version पर लागू होता है, और उसने enterprise product revenue को maximize करने के लिए इसका इस्तेमाल किया
  community भी जानती थी कि किसी specific version पर license लगा देने के बाद उसे वापस नहीं लिया जा सकता, और यह भी कि जिस point से वह license लागू हुआ है वहाँ से fork करके version-wise अपना “नया” project बनाया जाए तो उसे open source बनाए रखा जा सकता है
  आगे यह कैसे आगे बढ़ेगा, देखना दिलचस्प होगा, और लगता है कि यह भविष्य में software licensing का case study बनेगा। उम्मीद है OpenTF long term में कैसा बनेगा, यह देखने लायक होगा

  • community impact और response के हिसाब से यह Hudson और Jenkins के split के सबसे करीब लगता है। license वाला हिस्सा अलग है, लेकिन: https://en.wikipedia.org/wiki/Hudson_(software)
    ऐसी चीज़ों में Oracle लगभग हमेशा शामिल लगता है, लेकिन Terraform में surprisingly ऐसा नहीं था :D
  • “project version से जुड़ा license” और “project खुद से जुड़ा license” अलग करने की कोई वजह नहीं है। HashiCorp के पास future licenses बदलने का अधिकार था, और किसी के भी पास पुराने versions का उपयोग जारी रखने या fork करने का अधिकार था। असल में यहाँ वही हुआ है
  • historical तौर पर Hudson/Jenkins codebase को देखना भी दिलचस्प हो सकता है

• कहा गया है कि “नाम के बारे में कुछ legal experts से सलाह चल रही है, और ‘TF’ के इस्तेमाल की वजह से OpenTF भी final नाम न हो सकता है”
  यह दिलचस्प है कि सिर्फ नाम में TF होना भी समस्या बन सकता है
  स्रोत: https://github.com/opentffoundation/opentf/issues/273#issuecomment-1706947318

  • यहाँ potential issue wordmark है, यह पता चला
    अधिक जानकारी के लिए https://en.wikipedia.org/wiki/Wordmark देखें
    मैं env0 का founder हूँ और OpenTF initiative को co-lead कर रहा हूँ
  • मुझे लगता था कि शुरुआत से ही terraform की जगह xenoform इस्तेमाल करना चाहिए था। जैसे OpenXenoform और xf command वगैरह
  • मिलते-जुलते कारण से YP, NIS बन गया था
    https://en.wikipedia.org/wiki/Network_Information_Service

• मैं दो चीज़ें request करना चाहूँगा। पहली, modules और providers दोनों के लिए standalone registry package दिया जाए तो अच्छा होगा। मुझे सिर्फ Artifactory के बारे में पता है, लेकिन Nexus इस्तेमाल करने वाले environment में एक और बड़ा repository software नहीं चलाना चाहता
  दूसरी भी इससे जुड़ी है: provider modules को ज्यादा आसानी से fork करने की सुविधा होनी चाहिए। अभी की तरह locally build करके colleagues को binaries manual copy करके distribute करना, या खासकर जब upstream CLA sign करने को कहता है तब PR accept होने का इंतज़ार करना, अच्छा workflow नहीं है

  • पहली request को थोड़ा और समझा सकते हैं? अगर आप private provider/module registry चलाने के लिए self-contained binary चाहते हैं, तो ऐसे कुछ open source projects मौजूद हैं, और DockerHub या GitHub Container Registry जैसी OCI registries के जरिए providers distribute करने का proof of concept भी हमने किया है
    इस use case के लिए OCI registry काफी fit बैठती है: https://twitter.com/opentforg/status/1696913055576387599
    यह proof of concept जल्द ही public RFC बनेगा
    दूसरी request के बारे में, मैं जानना चाहूँगा कि आपके मन में ideal workflow कैसा है
    मैं Spacelift में काम करता हूँ, और committee-led model में जाने तक OpenTF Project का interim Technical Lead हूँ

• “terrafork” नाम रखना चाहिए था

  • OpenCorp भी चल सकता है। आखिर Terraform सिर्फ 1 product है: https://news.ycombinator.com/item?id=37393844

• अच्छा लग रहा है। test कर पाने के लिए https://github.com/opentffoundation/roadmap/issues/8 का इंतज़ार कर रहा हूँ
  source से build कर सकता हूँ, लेकिन अगर संभव हो तो release build इस्तेमाल करना चाहूँगा

• सरसरी नज़र डाली, docs बेहतरीन लग रहे हैं। Terraform internals पर थोड़ा काम कर चुके व्यक्ति के तौर पर, इस codebase पर काम करने वाले developer के लिए यह काफी बड़ा improvement लगता है
  शुरू करने के लिए अच्छा overall overview देता है। बढ़िया काम

  • ठीक-ठीक नहीं जानता कि आप किस docs की बात कर रहे हैं, लेकिन अधिकांश docs original repository से trademark-related हिस्से हटाने के अलावा ज्यादा बदले नहीं हैं
    अगर docs अच्छे हैं तो credit Terraform Core developers को जाता है
    मैं Spacelift में काम करता हूँ, और committee-led model में जाने तक OpenTF Project का interim Technical Lead हूँ

• पूरी तरह side note है, लेकिन dark background पर logo का गहरा नीला रंग काफी अजीब दिखता है
  सफेद outline भी पर्याप्त मोटी नहीं है, इसलिए dark background से overlap होने पर pixels ज्यादा उभरे हुए दिखते हैं

  • हाँ, यह निश्चित रूप से minor design nitpick है, लेकिन यह TensorFlow logo जैसा भी दिखता है, इसलिए एक पल के लिए लगा कि कोई group Google से project को अलग कर रहा है

• क्या किसी के पास इस codebase और आखिरी “continue to use करना ठीक है” Terraform license commit के बीच diff है?
  नए license controversy और बदलावों की वजह से असल में क्या बदलना पड़ा, यह मुझे ठीक से समझ नहीं आ रहा

  • GitHub में “compare” feature है। हमने जिस point से fork किया और current main के बीच का diff यहाँ देख सकते हैं: https://github.com/opentffoundation/opentf/compare/8a085b427b74ce3829500a59508b77465f1bbef0...a7d8cdd3eeaac968765c6819222606add3720ecf

• GitHub page पर logo को dark background पर improvement की जरूरत लगती है। खासकर dark text पर हल्की outline आती है, जो alpha bleed जैसी दिखती है और aliasing बची रहती है