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?

Parent: always, when in a component resource. Otherwise, whenever it seems sensible. dependsOn: never, unless it's needed to get stuff working.

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.

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 !

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.

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.

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