:wave: I’ve been seeing pulumi dependency graph pr...
# kubernetes
m
👋 I’ve been seeing pulumi dependency graph problems when using
k8s.yaml.ConfigFile
. In simplified terms, I have two yaml files:
foo.yaml
and
bar.yaml
, each of which defines multiple resources. The resources in
bar.yml
depend on those in
foo.yaml
. Thus, my pulumi (typescript) code looks something like:
Copy code
const foo = new k8s.yaml.ConfigFile("foo", { file: "foo.yaml" });
const bar = new k8s.yaml.ConfigFile("bar", { file: "bar.yaml" }, { dependsOn: foo });
however, when pulumi runs the update, it starts creating the resources under
bar
first.. and of course they fail. it actually starts retrying them 5 times, and sometimes they’ll eventually succeed because the resources in
foo
got created in the meantime, but the behavior is non-deterministic and fails very often. Do you know why pulumi isn’t waiting on
foo
resources to be created before creating the resources in
bar
?
looks like
k8s.yaml.ConfigFile
is a
CollectionComponentResource
.. is that not an acceptable “Resource” to pass as a value for
dependsOn
?
hmmm maybe i should be passing
dependsOn: foo.resources
well.. that doesn’t compile, but im gonna try
dependsOn: foo.resources.apply((m) => Object.values(m))
seems overly complex for a seemingly common use-case, but let’s see
c
This problem might be more widespread than just with Configfile. I have the same issue when I have a resource depend on a helm chart. The resource will be applied before the helm chart deployment is fully complete
👍 1
m
thanks for the data point! are you passing
dependsOn: chart
or
dependsOn: chart.resources.apply((m) => Object.values(m))
?
i just tried the
.resources.apply(…)
approach and it seems to have worked
it would be nice if pulumi auto-expanded CollectionResources though..
c
interesting! i was just passing the
chart
variable
g
This is the same underlying issue as https://github.com/pulumi/pulumi-kubernetes/issues/861 This affects the YAML and Helm SDKs, and we’re currently working on a fix.
👍 1