Provide more flexible ways to set tags

[mbbush]

What problem are you facing?

I would like to be able to apply certain tags to large groups of my managed resources, without having to add patches everywhere, similar to terraform's concept of default tags.

How could Official AWS Provider help solve your problem?

Adding a new field to the ProviderConfig schema could provide a way to allow users to specify this. It could also provide a way for users to opt out of the default tags, as requested in #1141.

Proposed schema

I'm sure this could be improved, but here's a rough idea

spec:
  resourceTagging:
    userDefined:
      team: blue
      managed-by: crossplane
      reconciled: continuously
    builtIn:
      disabled:
        - crossplane-kind
        - crossplane-name
        - crossplane-provider-config

This would disable the three built-in tags, and add three additional user-defined tags to every resource which uses this providerconfig. It could provide a mechanism for introducing additional built in tags in an opt-in manner, and allow practitioners to apply different tagging configs to different groups of resources by managing different provider configs.

Additionally, while about 2/3 of the provider-aws resources have a spec.forProvider.tags, all of them have a spec.providerConfigRef.name, so I can write a template/composition/function/whatever to always set the provider config, without needing to know which resources support tags and which don't.

Related functionality

Some things this might impact or relate to, that would need some work to determine how/whether to handle:

• The fact that various tags fields have special code for handling them in upjet, even though they only apply to provider-aws
• The way we handle tags vs tags_all

[kirek007]

If possible it should be also possible to define ignored tags (especially patterns), exactly like it's done in in terraform aws provider

[mbbush]

@kirek007 could you please explain a bit more about your use case for ignoring tags? It seems like the primary motivation on the terraform side is when certain tags are managed by external systems. But I think (although I haven't verified) that in that case crossplane provider AWS will just late initialize the externally managed tags into its spec.forProvider.tags. Have you observed this? Does it create problems, like crossplane trying to revert updates to the tags made by external tools?

Some more details would be great.

[kirek007]

@mbbush Thanks for replay, I've tried it and provider was trying to remove 3rd party tags.
But now when I'm thinking more about it, I'm using argoCD, so when lateInit added these to the object argocd might wanted to remove extra tags (that caused issues, because I don't have permission to create or remove these specific tags)
I'll do more tests around it! Thanks :)

[kirek007]

@mbbush it looks like this could be done using default_tags that is supported by terraform-aws-provider. It would be possible to configure it the same as I've done it in my PR. #1178
But built-in tags is different story.

[github-actions]

This provider repo does not have enough maintainers to address every issue. Since there has been no activity in the last 90 days it is now marked as stale. It will be closed in 14 days if no further activity occurs. Leaving a comment starting with /fresh will mark this issue as not stale.

[github-actions]

This issue is being closed since there has been no activity for 14 days since marking it as stale. If you still need help, feel free to comment or reopen the issue!