Dashboard › institutional-transition-lab › Distillation
a0b1d828-ba35-4934-88d4-8ef358bceb06["lore_tm_v1_DMy6LsYUXweCr7HQu3gtvpImzrdZ4Qjq2PKd6oZKEbk"]
opentofu-github-pr-2953; reviewed removed TSC notes in patch:9 through patch:12. Frozen model codings still had not been inspected in this segment.opentofu-github-pr-2953 patch:9 removes TSC/2024-02-21_NOTES.md. Attendees listed: Igor Savchenko (@DiscyDel), Roger Simms (@allofthesepeople), Roni Frantchi (@roni-frantchi), and Wojciech Barczyński (wojciech12).TSC/2024-02-21_NOTES.md records 6 comparison/migration-tool positions in order: 1. adding a website compatibility table was rejected unanimously; 2. more strongly emphasizing that OpenTofu is a “drop in” replacement—“100% compatible with TF 1.xxx to OpenTofu 1.xxx”—was approved by Roni, Roger, Igor, and Jim, opposed by Wojciech, with the development team asked to determine implementation; 3. adding or improving a “why OpenTofu” page was approved unanimously, with the development team asked to determine implementation; 4. a Terraform-to-OpenTofu migration check command split 3–2—Roger, Igor, and Jim for; Roni and Wojciech against—so the development team was asked to assess feasibility and return with a concrete proposal; 5. an OpenTofu-to-Terraform migration check command was rejected 4–1—Jim for; Roger, Igor, Roni, and Wojciech against; 6. a “compatibility mode” blocking OpenTofu-only features was rejected unanimously.TSC/2024-02-21_NOTES.md also says any steering-committee member could research other projects’ migration tools and return with information; no vote was considered necessary.opentofu-github-pr-2953 patch:10 removes TSC/2024-02-27_NOTES.md. On ecosystem migration guidance, the core team proposed splitting the migration guide into specific tested Terraform x.y.z → OpenTofu a.b.c paths, documenting required code changes and unsupported features and committing to fix discovered bugs on those paths; this proposal was accepted unanimously.TSC/2024-02-27_NOTES.md records a proposal from Janos for an .otf extension: when both xyz.tf and xyz.otf exist in one directory, OpenTofu would ignore xyz.tf, allowing Terraform and OpenTofu variants in one configuration. The TSC requested holistic RFC(s) covering divergence use cases on both the HashiCorp Terraform (“HTF”) and OpenTofu (“OTF”) sides, community feedback, and IDE handling rather than immediately deciding the mechanism.TSC/2024-02-27_NOTES.md records 2 module-variable-deprecation alternatives in order: 1. encode @deprecated: message or @deprecated{message} (syntax TBD) in the variable description—Terraform-compatible but rejected as magical, implicit, and slightly hacky; 2. add a first-class deprecated string field to the variable block—cleaner but incompatible with Terraform parsing, and potentially usable with .otf. Decision: reject approach 1 and consider approach 2 within the OTF/HTF discrepancies RFCs; the TSC noted it did not remember voting to accept issue https://github.com/opentofu/opentofu/issues/1005.TSC/2024-02-27_NOTES.md records agreement to implement functions in providers eventually. Although Terraform planned the feature for 1.8 and the provider SDK was already stabilized and released, the decision was to keep it out of OpenTofu 1.7 and add it to the 1.8 roadmap; proper issues/RFCs remained prerequisites to implementation.TSC/2024-02-27_NOTES.md records the Registry UI decision: prioritize an RFC for OpenTofu’s own formal registry.opentofu-github-pr-2953 patch:11 removes TSC/2024-04-03_NOTES.md. Attendees were Roger Simms, Roni Frantchi, Igor Savchenko, and Marcin Wyszynski; Jim Brikman was absent.TSC/2024-04-03_NOTES.md records 3 alternatives for the tofu keyword as an alternative to terraform: 1. reject temporarily pending acceptance of an RFC on language divergence; 2. accept only this contribution as an exception while blocking further divergence pending a long-term 1.8 solution; 3. reverse the prior policy and allow unrestricted divergence (“open season”). The TSC unanimously chose option 2. Igor noted compatibility with some tools would break but state encryption already did so and the exception could aid adoption; Roni, Roger, and Marcin supported treating it as a one-off exception with no more such changes until the divergence solution.TSC/2024-04-03_NOTES.md records concerns that continuing matching 1.6, 1.7, 1.8 version numbers could imply false OpenTofu/Terraform feature parity, conflict with Terraform module version constraints, and be weaponized by module authors hostile to OpenTofu. Igor stated OpenTofu could not follow Terraform versioning forever.TSC/2024-04-03_NOTES.md lists 5 versioning alternatives in order: 1. reserve 1.X for Terraform-parity features and use 2.X for OpenTofu-specific features, with duration of 1.X support TBD and state encryption already too late for this split; 2. continue the current versioning pattern; 3. solicit input from the development team and other stakeholders; 4. let module authors explicitly state that they do not want their work used with OpenTofu; 5. ignore Terraform versioning blocks in modules and require explicit OpenTofu constraints. Decision: discuss openly with stakeholders for one week and resume at the next meeting.opentofu-github-pr-2953 patch:12 removes TSC/2024-05-07_NOTES.md, whose visible portion presents the “RFC: Init-time Constant Evaluation Proposal” linked to issue https://github.com/opentofu/opentofu/issues/1042.TSC/2024-05-07_NOTES.md proposes adding an init-time constant-evaluation stage between configuration loading and internal graph construction so effectively constant variables/locals can be used in otherwise restricted contexts. Listed target use cases, in order, were: 1. module sources using variables/locals (#286, #1017); 2. provider for_each (#300); 3. module provider mappings from variables/for_each (#300); 4. backend configurations using variables/locals (#388); 5. lifecycle attributes that must be known (#304, #1329); 6. variable defaults/validation that must be known (#1336, #1514); 7. additional cases collected in #1258.var.library_version into source = "github.com/org/common-library?tag=${var.library_version}". Its provider example defines locals.region as {"primary": "us-east-1", "secondary": "us-east-2", "fallback": "us-west-1"}, applies for_each = locals.region to provider aws, sets alias = each.key and region = each.value, and maps a per-region module’s provider with aws = aws[each.key].TSC/2024-05-07_NOTES.md says proof-of-concept PR https://github.com/opentofu/opentofu/pull/1107 already supported variables in module sources and implemented the init-time constant-evaluation stage. The identified remaining technical hurdle was interaction with module-tree construction when for_each is evaluated in the constant context; the author did not expect it to be particularly difficult due to recent graph-structure work.-backend-config, and override files, solve many high-demand issues, and provide breathing room before a future redesign that might eliminate the extra evaluation stage.TSC/2024-05-07_NOTES.md, Igor Savchenko supported moving forward but requested performance testing on large configurations and warned that the change “will” break Terraform support. The supplied patch:12 excerpt ended mid-line at “@Wojciech Barczyński re”, so the remainder of the discussion and any final decision were not visible and could not yet be determined from this excerpt.