## 2024-05-07

## Agenda

### RFC: Init-time Constant Evaluation Proposal

https://github.com/opentofu/opentofu/issues/1042
This feature is a composable language addition that idiomatically solves many common top user requests (see linked issues):

- Module sources using variables/locals https://github.com/opentofu/opentofu/issues/286https://github.com/opentofu/opentofu/issues/1017
- Providers for_each support https://github.com/opentofu/opentofu/issues/300
- Module provider mappings from variables/for_each https://github.com/opentofu/opentofu/issues/300
- Backend configurations using variables/locals https://github.com/opentofu/opentofu/issues/388
- Lifecycle attributes must be known https://github.com/opentofu/opentofu/issues/304https://github.com/opentofu/opentofu/issues/1329
- Variable defaults/validation must be known https://github.com/opentofu/opentofu/issues/1336https://github.com/opentofu/opentofu/issues/1514
- Many more https://github.com/opentofu/opentofu/issues/1258

This proposal is an avenue to solve a very significant portion of the most frequently requested and top voted issues in OpenTofu and Terraform (see RFC for full related issue list). I am not proposing solving all of the above issues in a single PR/feature, but instead proposing a mechanism to support the addition of the above features in a simple and idiomatic way.

#### User Experience:

Many components of OpenTofu are dynamic and can refer to other objects/configuration. Users frequently attempt to use locals and variables in the above listed items, but are stymied by the fact that these items are quite limited in what they can reference.

This leads to significant additional complexity, with copy/paste between configurations being the default.  Some tools like Terragrunt offer ways to improve some of the common cases such as module sources, but many vanilla environments are severely lacking.  Another example is the -backend-config parameter and override files providing an incredibly hacky workaround to backend configuration limitations.

#### Technical Description:

OpenTofu's execution is split into two major components: setup to build the internal graph representation and evaluation of the graph.

What I propose is an init time constant evaluation stage be added between loading the configuration and building the graph.  This stage will be able to identify effectively constant values (variables/locals) which can be used during evaluation of the above.

Module Source Example:

```
variable "library_version" {
    type = string
}
module "my-mod" {
    source = "github.com/org/common-library?tag=${var.library_version}"
}

```

Provider Region Example

```
locals {
    region = {"primary": "us-east-1", "secondary": "us-east-2", "fallback": "us-west-1"}
}
provider "aws" {
    for_each = locals.region
    alias = each.key
    region = each.value
}
module "aws_resource" {
    source = "./per-region-module/"
    for_each = local.region
    providers = {
        aws = aws[each.key]
    }
}

```

#### Current State:

I have a [proof of concept](https://github.com/opentofu/opentofu/pull/1107) that supports variables in module sources, but more importantly implements an init time constant evaluation stage which supports that feature. The only remaining technical hurdle is how this interfaces with building the module tree when for_each is evaluated in the constant context. Given our teams recent work on the graph structure, I do not believe this will be a particularly difficult hurdle to overcome.

#### Summary:

I believe that by adding this init time evaluation we can idiomatically solve some of the largest pain points our users experience every day. In the future, we may re-design and re-engineer much of OpenTofu to remove the need for this evaluation stage.  However, this solves an incredible amount of our most important issues today.  It gives us the breathing room to decide on the technical future of the project without the pressure of users who are frustrated today.

#### Discussion:

- @Igor Savchenko thinks we should move forward - but we should have consider performance testing on large configurations and how those are impacted by the change. Also imported to note - this ***will*** break Terraform support.
- @Wojciech Barczyński reinforces that
- @Roger Simms 👍
- @Roni Frantchi asks - considering this is extending language features, and linters/language servers may raise errors or warnings if one uses this configuration - does that mean we will support that on .otf files only?

#### Decision:

- RFC accepted
- Ask core team to be mindful and rigorously test performance
- Strong recommendation to core team for consideration: if possible, the TSC’s preference is to roll out support for the above in iterations to limit the blast radius:
    1. Module source resolution
    2. Dynamic provider config
    3. …

### Alternate file extension .OTF for OpenTofu Specific Features

https://github.com/opentofu/opentofu/issues/1328

- Module and project authors can use .tf vs .otf to opt into different features but maintain support for both tools
- Easier for code completion / dev tools to support OpenTofu specific features
- Allows projects/modules to be written for OpenTofu and not Terraform if the author wishes (.otf only)
- Shows support / adoption of OpenTofu!
- Very little development effort required in OpenTofu

#### Discussion:

- TSC’s not entirely sure what’s the ask here - it’s been given green light for 1.8

### Next version of OpenTofu - what should it be? 1.8? 2.0?

- Implications on provider/module constraints?
- Feature comparison?

#### Discussion:

- @Roger Simms mentioned we wanted to get community feedback last time.
- @Wojciech Barczyński thinks we should carry on with the current versioning scheme while having our own release cycle as we gather more community feedback. He too fears jumping a major version can make people think OpenTofu introduces breaking changes that may deter them from joining.
- @Igor Savchenko currently, version compatibility and their mismatch in iterations confuses our users. We need something to distinguish between our own versions and HTF, while providing some kind of compatibility matrix? What is our versioning strategy?
- @Roni Frantchi is not concerned about 2.0 or 1.8 - either way, what concerns him is the provider/module constraints - for instance, right now providers may be adding constraints around new provider features support coming in HTF 1.8, which will “fail” compatibility as it checks OpenTofu’s version, despite beings supported in OTF 1.7

#### Decision:

- Come up with versioning strategy that is publicly available -
    - What is our release cadence?
    - Do we follow semver?
    - Consider in said strategy that there may be some perception that the release cadence of OTF is lower than that of HTF (despite OTF having more content in each) - should we have more frequent releases?
- Continue with current versioning schema for now (next version is 1.8)
- Open up an issue for the community to discuss whether we should change that versioning
- Open up an issue to track and come up with suggestion how the current or future versioning scheme will support provider constraints as support for new provider/module features are added on different version of OTF vs HTF

### Backends as Plugins

- We said we’re postponing it by 3 months, 3 months have passed.
- An oracle employee also reached out again, as they would like to add support for Oracle Object Storage as a Backend (and we blocked it by backends as plugins).

#### Discussion:

- @Igor Savchenko thinks it is not a priority still. As a TACO vendor, sounds great sure but - looking at the top ranking issue alternatives and what would benefit the community it does not seem remotely there.
- @Roger Simms similar
- @Wojciech Barczyński similar but we should reconsider again for next version.
- @Roni Frantchi similar

#### Decision:

Reconsider in 6 months

### The TSC never posted on GitHub summary since February

- We should discuss who owns this
    - AI: @Roni Frantchi will backtrack and post the summaries of all meetings dating back to Feb
    - From now on, whomever takes notes during the TSC meeting will also open the PR posting the public notes

### Change docs license in the charter to Mozilla as asked by Linux Foundation

#### Decision:

Yes.

