https://pulumi.com logo
Join Slack
Powered by
Is there an easy way to have all AWS resources cre...
# aws
g
Is there an easy way to have all AWS resources created by a stack include a tag with the stack name and/or project name? I want to avoid having all our infra engineers need to repeat these tags for all resources. aws:defaultTags in the configuration seems to only support static tags, so each stack would need to configure these explicitly (which isn't terrible, but also seems redundant and error-prone).
s
I don't know for sure, may be you are looking for resource URN? https://www.pulumi.com/docs/intro/concepts/resources/names/#urns
f
@gentle-zoo-32137 I think the current state-of-the-art on this is still this blog post: https://www.pulumi.com/blog/automatically-enforcing-aws-resource-tagging-policies/
We've had a copy of that code kicking around in our projects for about a year at this point. Works great, with one caveat: if you have any autoscaling groups, they put tags on in a slightly different way, which this post doesn't account for.
I can share a workaround for that if you're interested
g
Thanks! The auto-tagging part was what I was looking for. Although, relying on a static list of taggable resources (the "taggable" module) seems brittle - have you find a way to reasonable maintain or auto-generate this list?
f
In practice, it hasn't been an issue. The list is pretty big as it is, and we generally stick to the "core" AWS resources for our infrastructure anyway. I suppose you could add some logging that would surface any AWS resources that you try to use that aren't currently in that list... that could provide a signal to you to update the list.
l
In the classic (not-native) AWS module, the provider has the defaultTags property. I'm not sure how comprehensive it is, but it's likely to do what you need.
➕ 1
And it's much easier than either a policy or a stack transformation.
s
+1 for tenwit's suggestion. to add to what he said, this property will not retroactively apply to existing resources with no changes. The only time it's applied is on changes to a resource or on creation of a resource.
g
I know 
aws:defaultTags
can be set via the configuration, but if I want to programmatically set those tags - can I somehow do that in the default provider, or must I instantiate my own provider and specify it explicitly via the 
provider
or 
providers
options for all resources?
m
Very interested in the answer to that question myself, as I believe the default provider is tightly tied to the static stack configuration. I know you can define your own provider and explicitly pass it to each resource, but that's gross.
v
@full-artist-27215 we implemented the autotagging solution as a node package so that developers could just add the package as a dependency and run 
registerAutoTags()
in the 
index.ts
but saw some behaviour where due to pulumi inter-dependencies it was only working on a handful of the resources. How did you implement it?
f
@victorious-church-57397 We just have it as a Python file in our repository. All our Pulumi projects are in a monorepo and can just share the same code.
v
Makes sense, cheers for confirming mate :)
😎 1
m
@victorious-church-57397 we have implemented a similar pattern with a 
pulumi-components
node js package that is shared between projects and handles Custom Component Resources and autotagging. It does have some gaps in the coverage of resources, as you've noted, but it gets the majority for our use cases.
v
@millions-furniture-75402 I found it covered less than 50% of resources for auto tagging when we tried to implement it, would be curious to see the code if you could share it?
We experience problems with some of the resources stack transformations just not registering and we think it’s down to inter package dependency issues
m
Are you using the new registry components or custom components?
we basically did exactly what you did, stuffed the code from the blog post into a not package and call the function in our Pulumi plan
v
We’re just running a stack transformation across the resources in the stack, as per the blog post but it isn’t working for a lot of the resources in our stacks
I could understand it not working for custom resources but a lot of our stacks don’t leverage the custom resource
m
FWIW, I brought t up with our sales rep and CSM that this should be a first-class Pulumi maintained feature.
v
Ah we aren’t using the pulumi service just the open source stuff, I agree though it should definitely be a pulumi feature!
f
@millions-furniture-75402 Ooh, good point... I'll ping our rep on this as well 👍
m
I don't even mean in the Pulumi service, but rather the Providers or Engine
👍 1
v
To be fair I haven’t touched our auto tagging stuff for a while so might have another stab at it, see if anything’s sorted itself out. We were looking at potentially using peerDependencies to lock down the dependencies cross-packages
f
Looks like there's already an issue: https://github.com/pulumi/pulumi-aws/issues/1134
l
I know you can define your own provider and explicitly pass it to each resource, but that's gross.
I have been hit by sooooo many problems caused by using default providers that we now have linting checks to ensure that no resource is ever created without an explicit provider. And the new(ish) stack option 
pulumi:disable-default-providers
is great, too. Explicit providers will save you, someday!
m
You're probably right, I've held off because it seems tedious and fattens up declarations. I wish I could declare my own explicit provider the entire plan uses. I have a related issue that might drive me to declare explicit providers anyway https://github.com/pulumi/pulumi-aws/issues/1366
Migrating to the latest 
pulumi-aws
MAJOR version is going to be painful for us.
9 Views
Open in Slack
PreviousNext
Powered by