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

improvement: Introduce wg_tags to handle default_tags on provider level #1654

Closed
wants to merge 2 commits into from

Conversation

kbcz1989
Copy link

PR o'clock

closes: #1578, #1455(?), #1248(?)

Description

When default_tags are used on aws provider level, and the same tags are defined as input to this module, we end up with this issue:
default_tags always shows an update

If "tags" var is not set, no tags will be applied to resources which defines tag_specification.

So, either we have default_tags and do not set "tags". which leaves us with "empty" tag_specifications or we don't use default_tags.

This PR introduces new variable "wg_tags", which will be used on resources which define dynamic tags/tag_specifications if "tags" is not set. Backward compatibility is therefore fully retained.

There will be changes only if wg_tags is set, otherwise the module works the same as before.

Checklist

@daroga0002
Copy link
Contributor

daroga0002 commented Oct 20, 2021

what is difference between input_wg_tags and arleady existing tags input?

@kbcz1989
Copy link
Author

what is difference between input_wg_tags and arleady existing tags input?

Hello @daroga0002. If you have default_tags set on provider level, those will be applied to all resources, except for the "tag_spefications" and "dynamic "tag"" attributes of certain resources, where they rely on having "tags" set. Currently there is no way to apply "default_tags" and "tags" to this module without ending up with everlasting changes detected.

wg_tags would only be applied to "tag_specifications" and dynamic "tag" resources, which are otherwise unmanaged by default_tags, if they are set.

There actually should be no difference between wg_tags and tags in most situations. But if you want to move tags to default_tags on provider level, there is a discrepancy.

@daroga0002
Copy link
Contributor

there is a discrepancy.

what exactly? could you show plan diff here?

@kbcz1989
Copy link
Author

  # module.eks_main.aws_autoscaling_group.workers[0] will be updated in-place
  ~ resource "aws_autoscaling_group" "workers" {
        id                        = "<REDACTED>"
        name                      = "<REDACTED>"
        # (24 unchanged attributes hidden)

      - tag {
          - key                 = "some_key" -> null
          - propagate_at_launch = true -> null
          - value               = "some_value" -> null
        }
        # (4 unchanged blocks hidden)
    }
  # module.eks_main.aws_launch_template.workers_launch_template[0] will be updated in-place
  ~ resource "aws_launch_template" "workers_launch_template" {
        id                      = "<REDACTED>"
      ~ latest_version          = 12 -> (known after apply)
        name                    = "<REDACTED>"
      ~ tag_specifications {
          ~ tags          = {
              - "some_key" = "some_value" -> null
                # (1 unchanged element hidden)
            }
            # (1 unchanged attribute hidden)
        }
      ~ tag_specifications {
          ~ tags          = {
              - "some_key" = "some_value" -> null
                # (1 unchanged element hidden)
            }
            # (1 unchanged attribute hidden)
        }
        # (7 unchanged blocks hidden)
    }

if you want to use default_tags, in simplest case you would move anything you currently use in var.tags to default_tags.
Next TF run will apply default_tags on provider level to all resources, except in these dynamically-set attributes.
In these attributes, tags will be removed because var.tags is not set.

If you do set var.tags with same values as in default_tags, there will be changes detected on each run.

@daroga0002
Copy link
Contributor

seems be common provider error, for example:
hashicorp/terraform-provider-aws#19188
hashicorp/terraform-provider-aws#19387

@github-actions
Copy link

This PR has been automatically marked as stale because it has been open 30 days
with no activity. Remove stale label or comment or this PR will be closed in 10 days

@github-actions github-actions bot added the stale label Nov 21, 2021
@hatemosphere
Copy link
Contributor

@antonbabenko this is actually quite important with the current behaviour of the AWS provider's default tags. we had to disable the usage of default tags in TF state with this module due to not having the ability to set non-default tags only on tag_specifications and dynamic tag resources

@antonbabenko
Copy link
Member

If anyone wants to work on this one, please check this PR (around data source aws_default_tags) - https://github.com/terraform-aws-modules/terraform-aws-autoscaling/pull/169/files#diff-dc46acf24afd63ef8c556b77c126ccc6e578bc87e3aa09a931f33d9bf2532fbbR1

@github-actions github-actions bot removed the stale label Nov 25, 2021
@kbcz1989
Copy link
Author

The solution proposed by @antonbabenko is much better. I will close this PR and try to implement the proposed solution when I find some time.

@kbcz1989 kbcz1989 closed this Nov 29, 2021
@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 Nov 11, 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.

Global Tags - Note: Objects have changed outside of Terraform every run
4 participants