anyone have a solution to the helm chart post inst...
# kubernetes
s
anyone have a solution to the helm chart post install hooks not completing? I am using the right class:
Copy code
kubernetes:rbac.authorization.k8s.io/v1:ClusterRole (chart-ingress-nginx-mongodb-admission):
 warning: This resource contains Helm hooks that are not currently supported by Pulumi. The resource will be created, but any hooks will not be executed. Hooks support is tracked at <https://github.com/pulumi/pulumi-kubernetes/issues/555> -- This warning can be disabled by setting the PULUMI_K8S_SUPPRESS_HELM_HOOK_WARNINGS environment variable
Copy code
charts.forEach((chart) => {
      new helm.v3.Chart(
        `chart-${chart.name}-${namespaceName}`,
        {
          namespace: namespaceName,
          chart: chart.name,
          fetchOpts: { repo: chart.repo },
          values: load(readFileSync(`src/charts/system/${chart.name}/${chart.file}`, 'utf8')) as Input<any>,
        },
        { provider: k8sProvider, dependsOn: [eksCluster, eksNodeGroup, namespace] },
      )
    })
s
you can use
helm.v3.Release
instead of
Chart
s
are you sure? what does that pattern look like?
s
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
s
so use Chart to install the chart... then apply Release to finish it up?
s
use
Release
instead of
Chart
. So change
new helm.v3.Chart(
to
new helm.v3.Release(
s
lol okay I'll try. tyvm, I laugh because I thought I was advised last week to use Chart.
s
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
d
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 :)
s
I finally had success with this method, thanks everyone for your assists!
Copy code
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 },
  )
})
d
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
s
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.
but it is true my error messages for failing installs is still terrible
d
You'd usually put the dependsOn on the k8sProvider itself, which will cascade down to any resource that uses the provider
s
I'll give that a shot now thanks for the good idea