[Bug]: Configuration block metadata_options of launch_template is not granular enough

[james64]

Terraform Core Version

1.1.9

AWS Provider Version

4.58.0

Affected Resource(s)

aws_launch_template

Expected Behavior

Configuration options of launch_template are consistent with aws api in terms how independent they are. Setting/updating one is not forcing setting/updating of other.

Actual Behavior

Options in metadata_options block are not consistent with aws api. As an example, setting a value of http_endpoint also forces to set a value for instance_metadata_tags

Relevant Error/Panic Output Snippet

No response

Terraform Configuration Files

Start with tf config below and continue with reproduction steps.

resource "aws_launch_template" "foo" {
  name = "foo"
}

Steps to Reproduce

1. Apply the config
2. Compare state as described by both terraform and aws-cli
   • tf state contains "metadata_options": [],
   • aws ec2 describe-launch-template-versions ... returns "LaunchTemplateData": { "UserData": "" }
   • so far so good
3. Check whether we can udpate just single value in metadata_options using aws api
   • aws ec2 create-launch-template-version --launch-template-id <id> --launch-template-data '{"MetadataOptions": {"HttpEndpoint": "disabled"}}'
   • aws ec2 describe-launch-template-versions ... returns output below. Thus it is perfectly ok to do this as far as aws is concerned

"LaunchTemplateData": {
    "MetadataOptions": {
        "HttpEndpoint": "disabled"
    }
}

4. Reconcile terraform config and state with current reality
   • Update tf source and apply

resource "aws_launch_template" "foo" {
  name = "foo"

  metadata_options {
    http_endpoint = "disabled"
  }
}

  # aws_launch_template.foo will be updated in-place
  ~ resource "aws_launch_template" "foo" {
        id                      = "lt-0a0283da500e72b36"
      ~ latest_version          = 2 -> (known after apply)
        name                    = "foo"
        tags                    = {}
        # (7 unchanged attributes hidden)

      ~ metadata_options {
          + http_protocol_ipv6          = "disabled"
          + instance_metadata_tags      = "disabled"
            # (2 unchanged attributes hidden)
        }
    }

Plan: 0 to add, 1 to change, 0 to destroy.

5. Running this apply results in actual change on real launch template in aws. We were not be able to work around this by any combination of state editing or re-importing we have tried.

Here aws provider is adding two more options. They were not configured in tf source. They are not set on real resource. Aws api does not require this to be set. When editing a template in aws console, ui has drop down with three values for each setting: enabled, disabled, do not include in template.

Is there any reason why aws provider enforces this? There are two issues with this:

• It is a valid usecase to create a template which sets http_protocol but leaves instance_metadata_tags undefined for example. Provider does not support this atm.
• In some situations it creates new version of a template for now reason. This often triggers big changes in actual infrastructure (eks node rotations for example)

When we encountered this

We use old version of aws provider (3.70.0) in production which we need to update due to other issues. 3.70.0 does not have metadata_options.instance_metadata_tags at all. Updating to 4.58.0 adds this value to state. But instead of using null or empty value it sets it to disabled. This creates new version of a template which in turn triggers eks node group update. We cannot justify rotation of production nodes by this so we are kinda blocked by this.

Debug Output

No response

Panic Output

No response

Important Factoids

We have searched through bug reports. There are couple of those related to launch_template.metadata_options. However none of them seems to cover this particular issue.

References

No response

Would you like to implement a fix?

None

[github-actions]

Community Note

Voting for Prioritization

• Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
• Please see our prioritization guide for information on how we prioritize.
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.

Volunteering to Work on This Issue

• If you are interested in working on this issue, please leave a comment.
• If this would be your first contribution, please review the contribution guide.

[justinretzolk]

Hey @james64 👋 Thank you very much for taking the time to raise this! This was addressed with #30545, which was included in version 5.0.0 of the provider. With that in mind, we'll close this issue. If you experience additional issues with the provider, please do open a new issue to let us know.

[github-actions]

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.