https://pulumi.com logo
i

important-leather-28796

03/11/2019, 9:15 PM
I’ve got some issues with the
dependsOn
mechanism, it seems like it is not being respected by a helm chart that is the child of my
Component
. Details inside ->
My
Component
usage looks like:
Copy code
export const certManager = new CertManager(
  'certmanager',
  {
    cloudflareApiKey: new Config('cloudflare').require('apikey'),
    email: output(stack.identity.getOutput('email')),
    namespace,
    staging: new Config('certmanager').requireBoolean('staging'),
  },
  opts({ dependsOn: [clusterAdminBinding, namespace] }),
)
It is erroring on these specific dependencies. Both dependencies can be created fine. Do I need to propagate the
dependsOn
inside my
Component
definition to every child?
I printed my resolved
opts
just to be sure, they look good to me:
Copy code
options: { providers:
       { kubernetes:
          Provider {
            __pulumiResource: true,
            __providers: {},
            __protect: false,
            urn: [OutputImpl],
            id: [OutputImpl],
            cluster: [OutputImpl],
            context: [OutputImpl],
            kubeconfig: [OutputImpl],
            namespace: [OutputImpl],
            __pulumiCustomResource: true } },
      dependsOn:
       [ ClusterRoleBinding {
           __pulumiResource: true,
           __providers: {},
           __protect: false,
           urn: [OutputImpl],
           id: [OutputImpl],
           apiVersion: [OutputImpl],
           kind: [OutputImpl],
           metadata: [OutputImpl],
           roleRef: [OutputImpl],
           subjects: [OutputImpl],
           __pulumiCustomResource: true,
           __inputs: [Object] },
         Namespace {
           __pulumiResource: true,
           __providers: {},
           __protect: false,
           urn: [OutputImpl],
           id: [OutputImpl],
           apiVersion: [OutputImpl],
           kind: [OutputImpl],
           metadata: [OutputImpl],
           spec: [OutputImpl],
           status: [OutputImpl],
           __pulumiCustomResource: true,
           __inputs: [Object] } ] }
c

creamy-potato-29402

03/11/2019, 9:43 PM
@important-leather-28796 component resources are not respected by depends on this is a known bug cc @microscopic-florist-22719
work around is to depend on a specific resource in your component that you care about.
m

microscopic-florist-22719

03/11/2019, 9:45 PM
@creamy-potato-29402 I don’t think that’s the scenario here
@important-leather-28796 it sounds like you’re having trouble with resources inside the component starting to create before the resources listed in the component’s
dependsOn
are ready
Is that right?
i

important-leather-28796

03/11/2019, 9:47 PM
children of a Component seem to start being created before top level dependsOn - or so it seems
I just noticed the console printout to be missing my component at the top, it is pictured associated with a stack
m

microscopic-florist-22719

03/11/2019, 9:48 PM
Okay, that’s what I thought. That’s super weird, and definitely shouldn’t happen assuming everything is correctly parented
Oh interesting
That is very strange.
i

important-leather-28796

03/11/2019, 9:51 PM
Component is
'af:pulumi:CertManager'
- not sure where I could be making an error here. I’ll try to simplify and see if preview is correct at some point
m

microscopic-florist-22719

03/11/2019, 9:52 PM
yeah, your component definition looks correct to me
i

important-leather-28796

03/11/2019, 9:52 PM
destroy tree looks right
m

microscopic-florist-22719

03/11/2019, 9:53 PM
also possible if a bit unlikely that the CLI rendering did something weird here
i

important-leather-28796

03/11/2019, 9:53 PM
preview is good, running again
tree looks good now. Is there a bug to follow on the depends? I’ll just create a helper for now to propagate them
Didn’t seem to matter. Chaining my
dependsOn
yields the same errors.
I’d understand if I messed up the cluster role binding, but the namespace is a no-brainer.
m

microscopic-florist-22719

03/11/2019, 10:02 PM
well, they should propagate
i

important-leather-28796

03/11/2019, 10:03 PM
visually, the timing seems fine and the clusterRoleBinding/namespace are done, but I’m still unable to get the chart to run.
m

microscopic-florist-22719

03/11/2019, 10:06 PM
so just to be clear, what you're trying to do is expected to work. the
dependsOn
on the parent component should prevent its child resources from being created before they are ready.
b

busy-pizza-73563

03/11/2019, 10:06 PM
Is
namespace
a
Namespace
resource instance? If so, can you use it in helm values like that?
i

important-leather-28796

03/11/2019, 10:07 PM
namespace as passed in to the
Component
is a resource instance.
inside the component it is destructured:
Copy code
const { cloudflareApiKey, email, namespace: namespaceObject, staging = false } = args
    const namespace = namespaceObject.metadata.name
and I added
dependsOn: [namespaceObject, crds]
to the chart
b

busy-pizza-73563

03/11/2019, 10:08 PM
Oh, ok, cause in the first snippet you had
namespace
in both helm values and
dependsOn
.
i

important-leather-28796

03/11/2019, 10:09 PM
right, I tried to be careful there but I believe it is accurate - ts types help here.
b

busy-pizza-73563

03/11/2019, 10:12 PM
What's strange is it looks like it resolves
namespaceObject.metadata.name
before actually creating the namespace...
i

important-leather-28796

03/11/2019, 10:12 PM
so something else is wrong. the namespace is clearly created and
info
on creation is still failing on the retries e.g.
Retry #5; creation failed: namespaces "development" not found
it does seem to resolve correctly as indicated by the retry message
i’ll change the namespace name to static just for kicks - that is a stack name at the moment
b

busy-pizza-73563

03/11/2019, 10:13 PM
Although it feels like that should just create stuff in
default
namespace and not complain about not finding
development
namespace.
i

important-leather-28796

03/11/2019, 10:20 PM
makes sense
adding a transform to the helm chart for namespaces had no effect
it is clear to me that the namespace
development
exists, I need to look again at permissions or something else.
I’ll pick this up tomorrow, approach is to go god-mode on permissions and see if things start working….then back up from there. The namespace exists, so something else is up.
4 Views