Why is `aws:autoscaling/group:Group` not in `_NOT_TAGGABLE_RESOURCE_TYPES`?

[agibralter]

Is there any reason not to include ASGs in _NOT_TAGGABLE_RESOURCE_TYPES? Right now it seems there's no way to avoid pulumi.log.warn(f"{args.type_} does not support auto-tagging") showing up when I run pulumi...?

[tlinhart]

It’s because technically ASG does support tagging, it just uses different format and, more importantly, an additional parameter than just a tag key and value (see https://www.pulumi.com/registry/packages/aws/api-docs/autoscaling/group/#grouptag). The warning just informs the user that the resource is not supported by the library as it would (as of now) have to somehow infer the value for the additional parameter which is required.

There are three options:

• Improve the warning to better describe what’s the issue. But this could get quite convoluted if there appear other resources with similar specialities.
• Handle this special case by adding some parameter to the registration function which would specify the behavior for the ASGs. But the drawback is the same as above. (CDK uses this approach as far as I can tell.)
• Leave it as is which I’d prefer.

[agibralter]

(Sorry for the delay!)

Hmm, ideally, it would be nice if there were a way to specify a configuration option to support ASGs. I can't think of a reason someone would want to auto-tag all their resources in a stack but not have their ASG or the instances that ASG spawns to have the same tags...

Something like:

tags={
    "env": "...",
    "project": "...",
}
register_auto_tags(tags, autoscaling_propagate_at_launch=True)

To effectively get:

aws.autoscaling.Group(
    ...
    tags=[
        aws.autoscaling.GroupTagArgs(key=k, value=v, propagate_at_launch=True)
        for k, v in args.tags.items()
    ],
    opts=ResourceOptions(parent=self),
)

Which is what I have in my codebase... but I have a permanent warning (warning: aws:autoscaling/group:Group does not support auto-tagging).

[tlinhart]

While I agree in principle, the practical aspect is definitely a bit more intricate. When it comes to autoscaling groups, there's a note in the documentation about the tags that might shed some light on why it's not that simple. Also, as noted in the documentation, the tags are not propagated to EBS volumes which is probably what you want to.

Autoscaling groups are not the only resources that create and manage another resources and some of them do not support propagating tags at all. Consider for example AWS Batch where the tagging support is even more complicated. The compute environment supports tags parameter, but that tags only this particular resource, not the created resources and there's no options for propagating tags like autoscaling groups have. You'd have to use tags on compute_resources parameter but still there's a catch, it's not applicable when using Fargate. So for example to tag the created ECS cluster, you have to manage a standalone aws.ecs.Tag resource. And I'm quite sure Batch is not the only service like this.

My intent si to keep the library quite simple. I strongly prefer a simple mental model with clear interface rather solving 100 % of possible cases. As noted above there will always be some exceptions to the rules. That's why I'm hesitant to solve this one particular problem and leave other cases that would deserve it as well to stay consistent untouched.

[agibralter]

Ahh hmm yeah I think that makes sense. What do you think about an option or means of suppressing the warning?

[tlinhart]

Sorry for the radio silence, I was trying to get a feedback from Pulumi community about the possibility to filter warnings but without a success to the moment.

Anyway, is the warning causing you any issues? It's there to bring your attention to the fact that you are provisioning resources which are taggable, and thus you expect them to receive the tags, but for whatever reason they won't get tagged automatically. I might use a Python warning for that which you could filter out, but I think Pulumi log is more appropriate because it's cross-language and could be used the same way in Node.js implementation.

[agibralter]

Hmm yeah I mean it's not causing any issues beyond a persistent warning in updates' diagnostics sections... I guess I can just ignore it.