Proposal: Internal/private variables or constants

[radeksimko]

Motivation

I found myself and some of my colleagues using variable definitions purely to decouple strings that would be otherwise repeated/copy-pasted elsewhere in configs. The caveat of that approach is that variables are always treated as something user can change any time from outside via flags or interactive CLI as part of apply/plan.

Examples

Imagine I'm given an AWS VPC ID + bunch of subnet IDs and I'm supposed to launch instances/ASGs into those. 👂 I hear you saying "Just use/create VPC/subnet data sources for this!", but that inevitable means for the user of a data source to have Describe/Get permissions for such VPCs/subnets, which would expose a lot more details about such VPC/subnet than is necessary for a given task.

If VPC/subnet example doesn't make much sense to you, think about S3 bucket shared across many accounts. Would you want everyone to have s3:HeadBucket, potentially s3:GetBucketTagging and more just because they want to put/read data from such bucket? Probably not.

Thought process

1. variable.private = true + variable.default

👂 I hear you saying "But now default field is being abused!". And I agree, maybe we should introduce yet another field, say value? Maybe we should actually make it the only new field?

2. variable.value or variable.static_value

Good, now we have just 1 field and it does what it should, but how could this interact with actual user variables in the future? What about cross-referencing? The filtering and interpolation logic/ordering may get quite messy.

3. constant

This would also make future contract between user-defined variables & constants very clear => constants are immutable, may only contain basic interpolation with other constants, variables are mutable and may interpolate other constant values inside default and description.

Example of HCL syntax

constant "shared_s3_bucket_arn" {
  value = "arn:aws:s3:::my_corporate_bucket"
}

[apparentlymart]

This seems semi-related to (but not exactly the same as) #4084.

I currently have a rather-strange Terraform usage where we have a module whose entire purpose is to calculate CIDR prefixes for our VPCs and subnets using the cidrsubnet and cidrhost interpolation functions. It seems like I'd be able to eliminate a bunch of nonsense from that (currently (ab)using null_resource.triggers to stash some intermediate values) by exploiting the fact that constants can interpolate other constants.

However, for that use-case to work out we'd need to think a bit about how constants interact with modules/outputs. For example, can I create a library of constants as a re-usable module and then refer to them from a calling module?

module "constants" {
    source = "..."
}

resource "whatever" "example" {
    # seems fine
    baz = "${module.constants.thing_id}"
}

constant "derived" {
  # Seems less fine... interpolation here can't be done until the module is
  # evaluated, and requires core to be able to trace through multiple
  # levels of indirection to determine whether `thing_id` is derived only
  # from constants.
  value = "${module.constants.thing_id}-baz"
}

[jkodroff]

I'm using the vSphere provider and the lack of private/const variables comes into play when specifying a lot of vSphere-specific settings that can't be under TF control, for multiple reasons (not the least of which is that there's no resource for them).

Examples include:

• datacenter
• cluster
• domain

Some guidance on what to do for us poor vSphere folks would be much appreciated. If the answer is "use variables anyway and just set defaults", that's cool. Let me know and I'll add a PR to the vSphere docs saying so.

That's what I'm gonna do for now so I can move on with this, but a confirmation of "yeah, this is the thing to do" would be helpful.

[apparentlymart]

#15449 is now merged, and I think that addresses the use-cases described here, albeit with some different syntax.

I left a more detailed message with a usage example in my closing comment on #4084.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.