opentf/TSC/2024-01-30_NOTES.md

2024-01-30

Attendees

• Igor Savchenko (@DiscyDel)
• Marcin Wyszynski (@marcinwyszynski)
• Roger Simms (@allofthesepeople)
• Roni Frantchi (@roni-frantchi)

Absent

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

Agenda

1. Decide if Backends as Plugins are accepted as a roadmap item
   1. Context This is about accepting it as a long-term roadmap item - ie committing ourselves to doing it at some point, not necessarily for the specific implementation described in the RFC. Reasoning: We have many community members and companies wanting to get state backends in. We’d like to be able to answer “We’re not doing this, as we’ll be doing backends as plugins to handle it.” For this, we need this accepted by the TSC as a medium/long-term roadmap item.
   2. Options
      1. accept;
      2. reject (not go this direction);
      3. postpone the decision;
   3. Decision: postpone for 3 months Reasoning: this is not a key feature for our user base, and given that Terraform is seeing an increase in velocity, we need to churn out things that make a difference for average users.
2. Decide if we accept the Allow specifying input variables as unknown in tofu plan proposal as a feature
   1. Context
      • OpenTofu supports unknown values very well (e.g. outputs of not-yet-applied resources). This works well, but is not supported across statefiles. OpenTofu users commonly orchestrate multiple statefiles as a single "component" leading to multi-statefile plans, and unknown values that stem from a different statefile than your own.
      • Current solutions either use placeholder values (Terragrunt I believe), which are error prone as users sometimes accidentally apply the placeholder values, or they just use the previous variable value for the planning phase, which hides the actual blast radius a change in a statefile will have.
      • The goal here is to introduce the ability to mark an input variable of a tofu config as unknown during plan-time. This way all this tooling can properly signal what is actually the case - the variable is not currently known, due to changes in dependency statefiles. Leading to no error-proneness, and no hidden blast-radius.
      • This also involves making sure in the apply phase that all unknown inputs from the plan have been fully specified.
      • The issue contains a PoC in a comment, the expected changes required are limited, and mostly plumbing, as it's only further exposing existing functionality.
      • The goal here is to show momentum as a project, and at the same time provide better building blocks for external tooling.
   2. Scope of acceptance Accept it as an enhancement we'd like to introduce. The core team will iterate on the technical details, rfc and pick the rollout strategy / release we'd like to have it in.
   3. Decision Not ready to make a decision, please continue the investigation.
   4. TSC notes
      • research the possibility of implementing it as part of remote operations for the “cloud” backend. Also, make sure that it plays well with the vision of Terragrunt;
      • this potentially breaks an implicit contract that the plan indicates all changes made to the environment. With external inputs, the plan stops being 100% deterministic, which can break assumptions around processes like policy-as-code depending on the plan file. We should make this discussion part of the RFC;