https://pulumi.com logo
Join Slack
Powered by
This message was deleted.
# general
s
This message was deleted.
b
dependsOn
is not inherited by 
parent
. If everything in your component resource was given, 
dependsOn: this
than I think you'd get the behavior you want.
c
👍 thank you Joshua, I’ll give it a go
hmm that’s causing some strange race condition errors on some resources. I’ll have a delve elsewhere.
maybe promises or something
b
I wonder if having the 
dependsOn: this
is causing a weird chicken-before-egg issue. Alternatively your 
ComponentResource
could take in a 
dependents
array and then you could pass that array to all it's children so they wouldn't technically depend on the component resource. Whatever ends up working, just need that dependency to be passed down
c
Going down the rabbit hole, I found this undocumented method on 
componentResource
, 
async initialize()
here https://github.com/pulumi/pulumi/pull/3676, but after converting my certificate creating component to use initialize, the 
dependsOn
on my other 
componentResource
s still don’t work. There must be a way to tell one “external” (written by me) ComponentResource, to wait for another one to finish constructing it’s children… surely?
(i see it is documented, but the idea that resources inside initialiaze will complete before registerOutputs is interesting and not mentioned, Not helping my case though.
b
There must be a way to tell one “external” (written by me) ComponentResource, to wait for another one to finish constructing it’s children… surely?
I would imagine this would only work if both 
ComponentResources
pass those dependencies down to their children.
Pulumi conceptually has 2 different dependency graphs. The first graph is the parent/child graph. This has no affect on infrastructure provisioning and it mostly useful for logically grouping resources and for display purposes. This is the graph that you see in the CLI output. It defaults to the parent being the 
Pulumi.Stack
resource or to a 
Provider
, if one is given. You use 
parent: this
inside `ComponentResource`s so that your resources are logically grouped, but again this graph has no affect on resource provisioning. The second graph is the actual dependency graph. This is generally inferred by the `Output<T>`s that get passed around as those carry dependency information. You can also set explicit dependencies with the 
dependsOn
property, but those are always in addition to any inferred dependencies - you cannot override existing dependencies. The difference is necessary because the parent/child graph is 1:many while the dependency graph is many:1, because a resource must be able to depend on (and wait for) more than 1 resource, but a many:1 relationship is not conducive to logical grouping. This is why there is a separation. So this is why a 
ComponentResource
's children don't depend on their parent 
ComponentResource
. There is nothing that the 
ComponentResource
is provisioning that the children need to wait for, unless you explicitly say otherwise. If you have 
ComponentResource A
and you have 
ComponentResource B
and you want the children of 
B
to wait for the children of 
A
to finish provisioning, than you will somehow need to get those child resources into the 
dependsOn
property of the children of 
B
. Or at the very least you could use only `A`'s bottom dependent, the last provisioned resource would suffice to cause all of `B`'s children to wait for 
A
.
c
Thank you Joshua I really really appreciate the time and effort you’ve gone into for this excellent explanation. Sincerely. I’m going to go back and make a smaller project to fully understand this concept and maybe re-think how I architect some things. Thanks again, super helpful. Jon x
b
good luck!
141 Views
Open in Slack
PreviousNext
Powered by