Skip to content
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

fix: do not pass metadata_options if variable is null #95

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

ranimbal
Copy link

Setting the metadata_options explicitly in the AWS launch template is not supported in certain regions. The error we get is:

You must use a valid fully formed launch template; specifing HttpProtocol metadata options for an instance is not supported in this region.

This fix sets the metadata_options only if the value passed in is not null.

As described in hashicorp/terraform-provider-aws#25227, version 5.0.0 of the terraform-provider-aws fixed the issue of removing default values from the launch template. Hence this fix also upgrades the AWS terraform provider to that new version.

@adamacosta
Copy link
Collaborator

I'm probably going to incorporate this idea into a more general rework branch. This has an issue right now, but it's also an issue in the original code. You can't set just one part of the metadata options. We really need to be doing a lookup call with a default for each individual field and not assuming all of the keys always exist in the map passed to the variable, at least not if we want the type constraint to be map(any) as is currently the case.

@ranimbal
Copy link
Author

I'm probably going to incorporate this idea into a more general rework branch. This has an issue right now, but it's also an issue in the original code. You can't set just one part of the metadata options. We really need to be doing a lookup call with a default for each individual field and not assuming all of the keys always exist in the map passed to the variable, at least not if we want the type constraint to be map(any) as is currently the case.

Sounds good. Should I close this pull request then with a reference to the new rework issue once you create it?

@adamacosta
Copy link
Collaborator

You can leave it. I'll take care of the linking and closing when it happens.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants