https://pulumi.com logo
#typescript
Title
# typescript
m

modern-petabyte-38275

12/08/2022, 12:58 AM
not sure if this is a Typescript but curious on what people thought about “parent” and “dependsOn” usage for custom options. What is your thought process on when to use either of those or both?
l

little-cartoon-10569

12/08/2022, 1:05 AM
Parent: always, when in a component resource. Otherwise, whenever it seems sensible. dependsOn: never, unless it's needed to get stuff working.
c

clever-sunset-76585

12/08/2022, 1:55 AM
Agree with @little-cartoon-10569 for usage of
parent
. For
dependsOn
, I do sometimes want to create an explicit dependency on a different resource than in addition to the implicit dependency created via the resource's input args. It's rare that I have to do that though. For example, I recently had to do that with the AWS
CertificateValidation
resource due to an oddity with that resource when it comes to validating certificates that have wildcard SANs.
m

modern-petabyte-38275

12/08/2022, 3:44 AM
what would be another specific example if you dont mind for “needed to get stuff working”? does
parent
have a wait-till-available behavior to it? @clever-sunset-76585 or @little-cartoon-10569 thanks !
c

clever-sunset-76585

12/08/2022, 3:55 AM
I can't think of another example for
dependsOn
from recent memory, if that's a clue for how often I have to use it 🙂
does
parent
have a wait-till-available behavior to it?
It basically establishes a parent-child relationship but I don't know (don't remember) if just by using that Pulumi waits for the parent resource to be available before creating the child. It's usually not a concern when you have a true parent/child relationship since the child resource typically would already have some sort of an implicit dependency on some parent resource property like its
id
,
name
,
arn
etc. The
parent
allows you to visually represent that relationship. Also I might be wrong but I think if the parent resource needs to be replaced then all child resources under it will also get replaced, even when there isn't an implicit dependency on the parent in any of its children. The same is true for a targeted destroy (
pulumi destroy --target <parent-urn>
) of a parent I believe. But my memory is a bit rough on this part of the
parent
resource option behavior.
l

little-cartoon-10569

12/08/2022, 5:55 AM
There is no provider implication of
parent
, not like wait-until-available.t is purely for the UI graph, and it adds a state dependency: you can delete a parent until its children are deleted.
Another use case for
dependsOn
in my codebases is BucketObjects (I have lambdas that trigger immediately on creation but depend on file uploads to S3). There's also a few virtual resources provided by AWS classic specifically for dependsOn. I can't find my code right now, but I know I create a resource somewhere that has no equivalent entity in the console: the provider implements the class specifically for other resources to dependsOn it, when something is ready. Maybe it's to do with load balancers or CloudFront distributions? Does it ring a bell with anyone?
m

modern-petabyte-38275

12/08/2022, 2:01 PM
got it. this all makes sense. i had a strange behavior in creating an rds cluster with clusterroleassociation and i tacked on a dependsOn for the roleassociation creation. thanks tenwit and praneet