Is there a pattern in Pulumi (typescript) Componen...
# general
g
Is there a pattern in Pulumi (typescript) ComponentResources for building “adder” functions… ie lets say I created a
Team
component resource that creates a PagerDuty team and a Grafana Team. Can I create a function
addMember(email: string)
that is callable to add members to the team,, and do some kind of lazy instantiation of the underlying PD and Grafana resources?
h
This sounds a lot like my ask about tailscale a little bit ago, except I'm in python https://pulumi-community.slack.com/archives/CDE799L1M/p1704832498905509
i've got thoughts about how to do it in python, but it would definitely be an... unorthodox construction in the context of Pulumi
l
I do this sort of thing a lot. It's fine to do. You just need a call to a final
build()
method or similar, to construct the actual resource. The constructor won't be able to do it. And of course, your resource will have to be optional or at least not
readonly
, since it won't be set in the constructor.
h
oh, what I figured was a wrapping resource builder class with a secret inner component
l
There is no concept of "lazy" resource creation. Pulumi is declarative: no resources are created at construction time. Everything is eventually created. It's all "lazy".
h
so no pulumi resources get constructed until
build()
is called
l
You can create the teams at construction time and other resources later. That's fine too.
Depends on the requirements. The member resources wouldn't be created in the constructor. The team ones might.
I don't know how those classes work.
I use this sort of pattern for NACLs, for example. You can't create the NACL until all the rules are known; there is no rule class. So my component resource is actually a builder class, and the
build()
function creates the NACL with all the rules that were prepared by calls to the
addRule()
member.
h
yup, that's exactly my use case with the Tailscale ACL doc
l
But if you're working with something more like an IAM
Group
and
User
, you can create the Group in the connstructor, and create Users and UserGroupMappings (or whatever they're called) in an
addUser()
method.
In this case, you wouldn't even need a
build()
.
The convention in AWS' APIs, for things like WAF rules and IAM Policies, is to provide all the information at construction time. But it's just a convention. You've got a powerful programming language at your disposal, use it as you see fit!
And write unit tests.
g
The problem is that we aren’t always using something like the AWS API… and even in the AWS API, there are gotchas.. like building S3 Bucket Policies.