This message was deleted.

you can use

helm.v3.Release

instead of

Chart

are you sure? what does that pattern look like?

it's pretty much the same as with

Chart

. the difference is

Chart

just applies the evaluated yaml, whereas

Release

basically does

helm install

so you get all the features of Helm with your installation

so use Chart to install the chart... then apply Release to finish it up?

use

Release

instead of

Chart

. So change

new helm.v3.Chart(

to

new helm.v3.Release(

lol okay I'll try. tyvm, I laugh because I thought I was advised last week to use Chart.

IMO Release is usually better because you can just follow official documentation for maintaining your installation. I haven't run into a situation where Chart would be more appropriate yet

It all depends on usecase. Chart increases the amount of resources in a stack, as it tracks the individual k8s resources. This means an increased cost, but gives you finer grained access to individual resources for outputs, dependencies, and Pulumi's transformation support. This also means the Pulumi await logic is used to check when a resource is ready, such as making sure a Service of type Loadbalancer has an IP address assigned. Release defers this to Helm, so a single resource to track in pulumi, with support for hooks, but less ability to make modifications or depend on internal resources. Goes without saying, most of my k8s deployment issues have been from Helm being flakey :)

I finally had success with this method, thanks everyone for your assists!

pulumi.all([eksCluster, eksNodeGroup]).apply(([eksCluster, eksNodeGroup]) => {
  const datadogRelease = new helm.v3.Release(
    'release-datadog',
    {
      namespace: 'datadog',
      chart: 'datadog',
      repositoryOpts: { repo: '<https://helm.datadoghq.com>' },
      createNamespace: true,
    },
    { provider: k8sProvider },
  )
})

It's not really a good idea to create resources within

.apply

, as pulumi can't always track the resource. Given you're not using the inputs, you can just unwrap it and it'll work

I think I had to do that in order to get the Inputs for eksCluster, eksNodeGroup, which are exported in a different file as a dependson feature... if I don't need to do that I would of course prefer to not do so. Using dependson did not work without it.

You'd usually put the dependsOn on the k8sProvider itself, which will cascade down to any resource that uses the provider

I'll give that a shot now thanks for the good idea