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

feat!: Update autoscaling group tags -> tag to support v4 of AWS provider #179

Merged
merged 4 commits into from
Feb 14, 2022
Merged

Conversation

bryantbiggs
Copy link
Member

@bryantbiggs bryantbiggs commented Feb 10, 2022

Description

  • Update autoscaling group tags -> tag to support v4 of AWS provider which is now a tag block as opposed to a standard attribute
  • var.propagate_name has been removed
  • var.tags_as_map has been moved into var.tags and now var.tags just takes the standard map(string) map of key value pairs for tags. The tags provided are propagated to instances launched through the dynamic tag block
  • fix example for predictive scaling policy which caught some issues in the nested map lookup logic that has been corrected
  • var.tags are now automatically merged with var.tag_specifications

Motivation and Context

  • Avoids showing users a deprecation statement for tags on autoscaling group
  • Simplify tag usage and removes constant tag updates in each plan/apply

Breaking Changes

  • Yes

    • var.propagate_name has been removed
    • var.tags_as_map has been moved into var.tags and now var.tags just takes the standard map(string) map of key value pairs for tags. The tags provided are propagated to instances launched through the dynamic tag block

    Users will need to ensure that the value they are passing to var.tags is the standard map of key=value pairs (map(string))

How Has This Been Tested?

  • I have tested and validated these changes using one or more of the provided examples/* projects

main.tf Outdated
@@ -446,7 +446,14 @@ resource "aws_autoscaling_group" "this" {
delete = var.delete_timeout
}

tags = local.tags
dynamic "tag" {
for_each = { for tag in local.tags : "${tag.key}-${tag.value}" => tag }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
for_each = { for tag in local.tags : "${tag.key}-${tag.value}" => tag }
for_each = { for tag in local.tags : (tag.key) => tag }

Will this work, too? Value can be changed, so I don't think it is a good idea to use it as a part of a key in a map. WHYT? (Will this even work?)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I couldn't get that to work, it gives a bunch of errors like this

Error: Duplicate object key
│ 
│   on ../../main.tf line 448, in resource "aws_autoscaling_group" "this":
│  448:     for_each = { for tag in local.tags : "${tag.key}" => tag }
│     ├────────────────
│     │ tag.key is "Project"
│ 
│ Two different items produced the key "Project" in this 'for' expression. If duplicates are expected, use the ellipsis (...) after the value expression to enable grouping by key.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe combine values by key? The key should be unique anyway.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

well, in theory yes but not the way that we accept it. we let users pass in multiple tags and they can all have the same key, but the last key in the list is the one used - but the provider handles this deduplication, not us. I'll have to play around with this a bit and see

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, I wonder what will be the result if a user provides keys in several ways like this: {Project = "foo"} and {Project = "bar"}.

Without deduplication, there will be 2 keys in for_each created - Project-foo and Project-bar. Will it lead to constant changes after the creation?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we could do like this, but we'd have to drop the var.propagate_name variable terraform-aws-modules/terraform-aws-eks@33b4112

we can get away with this in the EKS module because we never offered users the ability to set propagate to true or false, just always defaulted to true

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's do it to reduce the number of potential issues related to constant changes.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let me take a deeper look later - not good to rush through this. I have some ideas that should solve both sides of this

@bryantbiggs bryantbiggs marked this pull request as draft February 10, 2022 19:57
@@ -557,7 +531,11 @@ module "complete_lt" {
},
predictive-scaling = {
policy_type = "PredictiveScaling"
predictive_scaling_config = {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure why this wasn't caught before but it was incorrect

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably nobody was using it :)

@@ -542,28 +532,28 @@ resource "aws_autoscaling_policy" "this" {
scheduling_buffer_time = lookup(predictive_scaling_configuration.value, "scheduling_buffer_time", null)

dynamic "metric_specification" {
for_each = lookup(predictive_scaling_configuration.value, "metric_specification", [])
for_each = can(predictive_scaling_configuration.value.metric_specification.target_value) ? [predictive_scaling_configuration.value.metric_specification] : []
Copy link
Member Author

@bryantbiggs bryantbiggs Feb 11, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

with the change on line 560 of the example now exercising this configuration, I had to make some adjustments to get this to work as intended and without errors


variable "tags_as_map" {
description = "A map of tags and values in the same format as other resources accept. This will be converted into the non-standard format that the aws_autoscaling_group requires."
description = "A map of tags to assign to resources"
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

brings everything back inline with other modules where users just provide var.tags

@bryantbiggs bryantbiggs changed the title fix: Update autoscaling group tags -> tag to support v4 of AWS provider fix!: Update autoscaling group tags -> tag to support v4 of AWS provider Feb 11, 2022
@bryantbiggs bryantbiggs marked this pull request as ready for review February 11, 2022 16:25
@bryantbiggs
Copy link
Member Author

ok should be ready for review now if you get some time @antonbabenko

@antonbabenko
Copy link
Member

@bryantbiggs I am pretty much off with corona since Wednesday. Only obvious PRs can be processed by me before Monday 🤯

@bryantbiggs
Copy link
Member Author

@antonbabenko no rush at all - sorry to hear, hope you feel better soon!

Copy link
Member

@antonbabenko antonbabenko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. To make this release a "breaking change" I need to include "BREAKING CHANGE" into the commit message (if I remember correctly). Fingers crossed!

@@ -557,7 +531,11 @@ module "complete_lt" {
},
predictive-scaling = {
policy_type = "PredictiveScaling"
predictive_scaling_config = {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably nobody was using it :)

@antonbabenko antonbabenko changed the title fix!: Update autoscaling group tags -> tag to support v4 of AWS provider feat!: Update autoscaling group tags -> tag to support v4 of AWS provider Feb 14, 2022
@antonbabenko antonbabenko merged commit 2c2a8a9 into terraform-aws-modules:master Feb 14, 2022
antonbabenko pushed a commit that referenced this pull request Feb 14, 2022
## [5.0.0](v4.11.0...v5.0.0) (2022-02-14)

### ⚠ BREAKING CHANGES

* Update autoscaling group `tags` -> `tag` to support v4 of AWS provider (#179)

### Features

* Update autoscaling group `tags` -> `tag` to support v4 of AWS provider ([#179](#179)) ([2c2a8a9](2c2a8a9))
@antonbabenko
Copy link
Member

This PR is included in version 5.0.0 🎉

@github-actions
Copy link

I'm going to lock this pull request 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 related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 28, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants