opentf/TSC/2024-02-17_NOTES.md

2024-02-17

Attendees

• Igor Savchenko (@DiscyDel)
• Marcin Wyszynski (@marcinwyszynski)
• Roger Simms (@allofthesepeople)
• Roni Frantchi (@roni-frantchi)
• Wojciech Barczyński(wojciech12)

Absent

• Omry Hay (@omry-hay)
• Yevgeniy Brikman (@brikis98)

Agenda

1. Decide on producing more specific migration paths from Terraform to OpenT

   1. Context e.g. from Terraform version x.y.z to OpenTofu a.b.c. This would enable us to better describe exactly what parts of the code users need to modify and what features may not be supported between those two specific versions.
   2. Options
      1. accept
      2. reject
   3. Decision: accept, unanimous

2. Decide if issue OpenTofu-specific code override should be accepted.

   1. Context as state encryption is a feature OpenTofu is adding which is not available to Terrafrom and we don't want to break compatibly for users trying out Tofu. This issue provides an option to create a new file type which would be used by OpenTofu but ignored by Terraform.
   2. Decision TSC would like to see a holistic RFC(s) in order to gather community feedback, provide alternatives and TFC to make decision on. Should consider capturing use cases of divergence from HTF to OTF and how these might be handled by IDEs etc.

3. Deprecating module variables.

   1. Context issue accepted to introduce mechanism of deprecating module variables. Options for this are:
      1. Approach 1: add deprecation as part of the variable description. e.g. add something like @deprecated: message or @deprecated{message}and Tofu would raise a warning with the message.
         • Advantages: Modules can use this while still supporting Terraform.
         • Disadvantages: "Magical" and implicit solution. Introduces a new, slightly hacky, mechanism.
      2. Approach 2: add the deprecation as an explicit deprecatedstring field in the variable block.
         • Advantages: First-class support, looking cleaner and nicer. Module authors can signal their support for OpenTofu by using this feature, and making their module not work with Terraform. Alternatively, module authors can use the .otf extension (if decided for, see above) to provide alternative code for OpenTofu.
         • Disadvantages: Modules using it will not work with Terraform, it will break on parsing the variable block.
      3. Decisions:
         1. Reject approach 1
         2. Consider how approach 2 fits with OTF/HTF. Possibly include as part of above requested RFC on handling discrepancies.

4. Functions in providers

   1. Context mostly a formality but do we agree "functions in providers" is something we want to do (without timeline or priority).
      • Note 1: Terraform 1.8 is adding this feature and the provider sdk, including this, is already stabilized and released.
      • Note 2: This is not a lot of effort and could possibly make the Tofu 1.7 release, if Terraform 1.8 is released before Tofu 1.7 (to ensure API is stable).
      • Note 3: Full RFC will follow, this is mostly an ask from the core team to ensure everyone is in agreement with adding the feature at all.
   2. Decisions
      • Agree feature should be added to the Tofu roadmap
      • Add to the Tofu 1.8 release, keep it out of 1.7 release, even if Terraform 1.8 is released wit the feature.

5. Registry UI

   1. Context previous decision to wait on this but community are now asking for it.
   2. Decision Please prioritise RFC of OpenTofu's own formal registry.