Giters

hashicorp / terraform

Terraform enables you to safely and predictably create, change, and improve infrastructure. It is a source-available tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned.

Home Page:https://www.terraform.io/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Terraform Module Registry incorrectly shows Inputs as required if default = null

JustinGrote opened this issue · comments

commented

See my module for example:
https://registry.terraform.io/modules/JustinGrote/azure-function-powershell/azurerm/

azure_active_directory_id is default=null, so it is an optional variable, but shows as required on the registry.

commented

Thanks for reporting this, @JustinGrote !

Your 0.2.1 link did not work for me but these did:

https://registry.terraform.io/modules/JustinGrote/azure-function-powershell/azurerm/0.2.2?tab=inputs
https://github.com/JustinGrote/terraform-azurerm-azure-function-powershell/blob/master/variables.tf#L61-L65

At a glance, it looks like the registry does not distinguish nil variables (no default) from variables intentionally set to null when determining if a variable is required.

commented

Same for the official consul module. Four variables are shown as required on the Terraform Registry page, even though all of them are optional as shown in variables.tf.

This is confusing for potential users of a module, so I hope it will get fixed soon!

commented

Sorry to bother but this is a very frustrating issue for many new users of the modules (I hear this rather often).

Is there any way to give this issue a higher priority?

commented

@jbardin @mildwonkey Any chance this can get fixed before the issue hits its 2-year birthday?

commented

@mildwonkey @jbardin sorry to do it, but any thoughts / progress / rumblings about this one for ya'll on the terraform team? Every time I see the disclaimer that we include in all module READMEs at Cloud Posse regarding this issue it hurts 😞

commented

Hi @Gowiem ! I checked in with our (internal) Registry team, and they are still aware of this issue. Unfortunately it's not something the terraform core team can do anything about, but the Registry team hasn't forgotten about it, and it's on their backlog.

commented

@mildwonkey figured it was something along those lines. Thanks for following up -- it's much appreciated!

commented

@mildwonkey bumping this again. one of my colleagues just randomly hit this and reviewing this thread is a real headscratcher for an issue that seems like a fairly low-hanging fruit?

commented
commented

wowzers. alright then well best of luck to you haha.

well folks looks like we're headed back to "workaround city."

commented

@jonassteinberg1: Speaking with the Registry team, the issue is slowly rising closer to the top of the list but currently no ETA.

commented

Also highlighting as problem here too

commented

Just to share how I've been getting around this issue in the meantime -- I've been setting the optional input variable's default to "" instead of null, and then utilizing locals.tf to check if the variable is equal to "".

If it is equal to "", then I will then set its local variable version of the input to null.
If it's not equal to "", then I will set the local version to what the user inputted.

Hope this helps someone! 🙂

commented

Hi everyone,
I came across the nullable flag:

variable "example" {
  type     = string
  nullable = false
}

Only available in Terraform v1.1.0 +

The default value for nullable is true. When nullable is true, null is a valid value for the variable, and the module configuration must always account for the possibility of the variable value being null. Passing a null value as a module input argument will override any default value.

Setting this doesn't do anything either in regards to this particular open case :(

variable "aci_dns_label" {
  type        = string
  description = "DNS label to assign onto the Azure Container Group."
  nullable = false
}

image

commented

Hi all,

This was fixed by the Terraform Registry team a couple months ago. We can actually see the fix in the screenshot in the comment just above this one: aci_dns_label is shown as an optional input with "Default: null" rather than as a required input variable.

A catch with this is that the registry only analyzes the module configuration during the initial import from GitHub and so this adjustment is only effective for module versions that have been published since this change was released. I don't know exactly when that was but I know it was in early August 2022, because I can see the registry team's code change at the beginning of August and the previous comment showing its effect was posted on August 12.

The registry does not ever re-visit modules that were previously loaded into it, so historical module versions that were imported with these input variables incorrectly marked as required will, unfortunately, always show the input variables in that way. Module authors will need to publish new versions of their modules for the update to take effect.

Because the fix has been merged to the Terraform Registry codebase and deployed, I'm going to close this. Thanks for reporting this and sorry for the delay in closing this issue once it was fixed.

commented

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.