Skip to content

coder_parameters of terraform module are not properly collected #8090

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
sthdev opened this issue Jun 20, 2023 · 11 comments · Fixed by #8195
Closed

coder_parameters of terraform module are not properly collected #8090

sthdev opened this issue Jun 20, 2023 · 11 comments · Fixed by #8195
Assignees
Labels
s1 Bugs that break core workflows. Only humans may set this.

Comments

@sthdev
Copy link

sthdev commented Jun 20, 2023

Hi,

I have created a Terraform module, coder-template-base, which contains all the basic resources and data elements for all my Coder workspaces in Kubernetes, since these are mostly identical for all my workspace templates. In particular, coder-template-base contains several coder_parameters in order to allow users to adjust e.g. the home volume size.

The actual Coder workspace templates use and parameterize this module, roughly like this:

module "coder_template_base" {
  source = "git::https://gitlab.company.com/coder-templates/coder-template-base.git?ref=1.4.0"

  image_name = var.image_name
  image_tag  = var.image_tag

  home_vol_size_default  = 5

 coder_agent_startup_script_extension = <<EOT
 echo "Hello world"
 EOT
}

This works fine, the Coder UI properly shows input fields for all coder_parameters of coder-template-base, as long as the templates that use this module do not define coder_parameters of their own. If the template defines additional coder_parameters like in the example below, the Coder UI only shows these additional coder_parameters, but not those of coder-template-base.

module "coder_template_base" {
  source = "git::https://gitlab.example.com/coder-templates/coder-template-base.git?ref=1.4.0"

  image_name = var.image_name
  image_tag  = var.image_tag

  home_vol_size_default  = 5

 coder_agent_startup_script_extension = <<EOT
 curl -SL ${data.coder_parameter.tool_download_link.value} | tar -zx
 EOT
}

data "coder_parameter" "tool_download_link" {
  name         = "tool_download_link"
  display_name = "Tool Download Link"
  type         = "string"
  default      = "https://example.com/tool.tar.gz"
}

It looks like the algorithm, which collects all coder_parameters does not examine the imported modules if it already finds coder_parameters in the template's terraform files.

@cdr-bot cdr-bot bot added the bug label Jun 20, 2023
@matifali matifali added the s1 Bugs that break core workflows. Only humans may set this. label Jun 20, 2023
@kylecarbs
Copy link
Member

Ahh, we shall fix this! Thank you for the report.

@kylecarbs
Copy link
Member

@sthdev what version of the provider are you using?

I wrote a test for this on v0.7.0 and it seems to work as expected (collecting child module parameters along with the parent).

@sthdev
Copy link
Author

sthdev commented Jun 20, 2023

I am also using 0.7.0.

To clarify: Setting up the workspace works without problems. It's just that the wizard to set up a new workspace does not show the parameters of the parent module if the child module also defines parameters. The workspace can still be created with the default values of the parent module's parameters. Therefore, I don't suspect the bug to be in the coder terraform provider but in the coder frontend. It does not seem to recognize that there are additional parameters for which the user can specify values.

@kylecarbs
Copy link
Member

Ahh, I see. It's odd because the parameters come out in the same format...

@sthdev
Copy link
Author

sthdev commented Jun 20, 2023

By the way, the Coder version is 0.24.0. I'll update to 0.24.1 and see how it looks.

@kylecarbs
Copy link
Member

I think it'll be the same, but worth trying!

@sthdev
Copy link
Author

sthdev commented Jun 20, 2023

You're right. The parent parameters are still not shown.

@ammario
Copy link
Member

ammario commented Jun 22, 2023

@mtojek can you look into this?

@mtojek
Copy link
Member

mtojek commented Jun 22, 2023

It looks like the algorithm, which collects all coder_parameters does not examine the imported modules if it already finds coder_parameters in the template's terraform files.

I suspect the culprit which is the function responsible for reading parameters in the right order. This routine examines local .tf or .tf.json files for parameters, which means that it can't retrieve dependent modules or their sub-modules. It just can't support it.

I think that we could partially fix this by appending remote parameters to the original list. I don't think that we should download all modules to check if they hide parameters. Anyway, if that solution makes sense, I can park some time for this in the next week.

@sthdev
Copy link
Author

sthdev commented Jun 22, 2023

Why don't you let terraform do the heavy lifting? terraform init should download all referenced modules.

@mtojek
Copy link
Member

mtojek commented Jun 23, 2023

Why don't you let terraform do the heavy lifting? terraform init should download all referenced modules.

We do, but terraform, or rather the Go library, does not respect the order of parameters and randomizes it. That's why we need to correct the behavior.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
s1 Bugs that break core workflows. Only humans may set this.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants