Hi. Is it possible to use

render_yaml_to_directory

without it affecting the state of my k8s cluster?

I have a bug in my pulumi code where a k8s custom resource (argo events sensor) was created without explicitly specifying a provider. Basically in this case it will use whatever the current k8s context as the provider. This leads to corruption (accidentally overwritten) in our production k8s cluster when we meant to deploy to a test cluster. Now, when I try to fix with explicit k8sprovider using "pulumi up", it try to replace the resource, but I got this error: error: resource xxxxx was not successfully created by the Kubernetes API server : xxxxxxx already exists I guess this happened because the replacement is try to create a new one first, and delete the old one. This of course will not work. What is best way to recover from this situation? Should pulumi be smart enough to detect that the explicitly specified k8s provider is the same as the default one used before and just simply ignore this?

Sharing this here in case it gets more traction 🙂

I’m using eks.Cluster to deploy a k8s cluster. I’d like to use calico vxlan for ipam, which means I need to delete the aws-node daemonset and then apply the calico-vxlan manifests prior to building the first nodegroup. is there a way to deploy the eks infra up to that point, ensure the daemonset doesn’t exist, and then subsequently deploy the remaining aspects of my stack? (ideally all during a single pulumi up invocation)

hey guys, is there a way to make pulumi skip crd installation when installing a helm chart?, edit: guess I could use transformations to do it. edit2: nevermind, there’s a parameter called_`skip_crd_rendering`_ in the

ChartOpts

initializer. 😄

Anyone know how to do the equivalent of

--set-file

on a k8s.helm.v3.Chart? Regular

--set

is done through

ChartOpts.values

, but its unclear to me how to supply a file as value. Am trying to get an install of Linkerd via Helm going, by porting https://linkerd.io/2.10/tasks/install-helm/ to Pulumi code

Anyone ever did storageclasses with volume expansion enabled and scaling a PVC? Pulumi does replacements instead of updates when i change the request size.

Hey everyone, how can I get the namespace property back from a helm chart deployment? https://www.pulumi.com/docs/reference/pkg/kubernetes/helm/v3/chart/#outputs claims that all input properties are ouputs, but there's no

redis.namespace

property. I want to retrieve it from the helm chart output as I need to ensure the secret retrieval for

redisPassword

happens after the helm chart has deployed.

const redis = new k8s.helm.v3.Chart("tyk-redis", {
        fetchOpts:{
            repo: "<https://charts.bitnami.com/bitnami>",
        },
        repo: "bitnami",
        chart: "redis",
        namespace: tykFargateProfile.selectors.apply(selectors => selectors[0].namespace)
    });

    const redisPassword = k8s.core.v1.Secret.get("redisPassword", `${/*namespace here*/}/tyk-redis`).data.apply(data => data["redis-password"]);

hey, how do you update coredns-custom with pulumi?

@gorgeous-egg-16927 would it be possible to get a review on https://github.com/pulumi/pulumi-kubernetes/pull/1706/ ?

So, I have a race condition present in one of my Pulumi programs, and I'm trying to figure out if there's a way to solve this problem. Basically, I have a

Deployment

that uses a

ConfigMap

, and also snags the

name

property of the

ConfigMap

for injecting as an environment variable. The abbreviated code is:

const myConfigMap = new k8s.core.v1.ConfigMap(...);
const deployment = new k8s.apps.v1.Deployment(
  "my-deployment",
  {
    spec: {
      template: {
        spec: {
          containers: [
            {
              name: "example",
              env: [
                {
                  name: "CONFIG_MAP_NAME",
                  value: myConfigMap.metadata.name,
                },
              ],
            },
          ],
        },
      },
    },
  },
);

My problem is that when I'm running an update, Pulumi does: 1. Create new

myConfigMap

. 2. Delete old

myConfigMap

. 3. Run update on

deployment

, including changes to point to new

myConfigMap

. This leaves a period of time between step 2 ending and step 3 ending where the injected name in my old version of

deployment

no longer points to a valid

ConfigMap

in our namespace. What I want to have Pulumi do is reverse steps 2 & 3: 1. Create new

myConfigMap

. 2. Run update on

deployment

, including changes to point to new

myConfigMap

. 3. Delete old

myConfigMap

. Is there a way to do this in Pulumi (have cleanup / deletion happen conditional on other resource updates completing)?

I'm using a pulumi ts codebase to deploy a helm chart that I've been running directly via helm cmds for a while. Pulumi successfully deploys the helm charts and all functions and health indicators perform as desired. I appear to be running into a superficial issue where pulumi believes the ingress objects are orphaned with no associated service backends however the ingress and services are functioning correctly to provide my api and webui components perfectly. REPO: https://github.com/usrbinkat/pulumi-kongee-on-k8s Bug / in flight troubleshooting details: https://github.com/usrbinkat/pulumi-kongee-on-k8s/issues/1

Super weird, destroying a cluster with AWS elb CDR’s, destroyed the nodepool, but left the CRD instances (not deployed via this stack) deadlocking the deploy completely. The CRD would not delete as stuff was still using it so the destroy fails. Apart from destroying in the right order, any way to prevent this deadlocking?

FYI - https://pulumi-community.slack.com/archives/CB36DSVSA/p1631645316033200

Cross-posting from #general, since I just realized this channel exists.

Hey, Im trying to use aggregated api layer from pulumi, e.g. this here: https://github.com/gardener/gardener/blob/master/example/90-shoot.yaml Unfortunately there is no crd definition for it to use with

crd2pulumi

. I have been able to make it work by writing all fields manually into something like this:

new k8s.apiextensions.CustomResource(
         "shoot",
             {
             apiVersion: "core.gardener.cloud/v1beta1",
             kind: "Shoot",
...

but its kinda hacky… Does anyone have an idea how to generate a typeful and documented

pulumi.CustomResource

class for something like this? The api is actually pretty well defined: https://github.com/gardener/gardener/blob/master/pkg/apis/core/types_shoot.go

solved: i'm hoping to trying out the new

Helm Release

but with

@pulumi/kubernetes-v3.7.1

I get

TSError: ⨯ Unable to compile TypeScript:
    index.ts(67,33): error TS2339: Property 'v3' does not exist on type 'typeof import("/home/user/Projects/pulumi/k8s/node_modules/@pulumi/kubernetes/core/index")'.

in messing with the new helm.release functionality i would like to know if there is a way to get the rendered yaml (before it is deployed - like a noop run) to debug issues like :-

Previewing update (ipd-eks-use1-sfx):
     Type                              Name                          Plan       Info
 +   pulumi:pulumi:Stack               pulumi-test-ipd-eks-use1-sfx  create     1 message
 +   ├─ pulumi:providers:kubernetes    k8s_provider                  create
     └─ kubernetes:<http://helm.sh/v3:Release|helm.sh/v3:Release>  signalfx-agent                           1 error

Diagnostics:
  kubernetes:<http://helm.sh/v3:Release|helm.sh/v3:Release> (signalfx-agent):
    error: Object 'Kind' is missing in 'null'

Hi 👋 Just updated a few dependencies today.. including

@pulumi/kubernetes

from

3.4.1

to

3.7.2

, and it's just started consistently getting 403's for a couple of

ConfigFile

resources:

Error: Error fetching YAML file '<https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.4.1/components.yaml>': 403 Forbidden
    Error: Error fetching YAML file '<https://github.com/jetstack/cert-manager/releases/download/v1.2.0/cert-manager.yaml>': 403 Forbidden

Any ideas why this might've started happening? The error call stack just points at this line of code. I can't see anything obvious that could cause it. Rolling back to

3.4.1

everything works again 🤯

Hey everyone! On implementing this https://github.com/pulumi/examples/tree/master/kubernetes-py-jenkins, getting the following issue. Any suggestions on how I could resolve this?

@sparse-park-68967 do you have a roadmap / timeline for the helm releases preview having issues addressed and going stable? Basically we're wondering if we should wait for it before going to production. Bearing in mind if we go ahead with helm chart resources then we'll need to tear them down before switching to helm releases; unless I'm missing something and this can be blue green somehow?

Is there a way to import all resources created by https://www.pulumi.com/docs/reference/pkg/kubernetes/yaml/configfile/ ? I've already applied the yaml file by hand and would now like pulumi to manage it.

message has been deleted

Why kubeconfig from my EKS cluster stop working?

How do I fix this?

It used to work fine

pulumi up

is just hanging indefinitely when trying to create

k8s.yaml.ConfigFile

for some CRD manifests in a directory.

k8s.yaml.ConfigGroup

is the same. Commenting out the block avoids the hang and works fine. They aren't mega CRDs, the biggest is ~550 lines. The code in question...

// Traefik CRDs
const crdDirectory = path.resolve(__dirname, "./crds");
fs.readdirSync(crdDirectory).forEach((filename) => {
  new k8s.yaml.ConfigFile(
    `crd-${filename}`,
    {
      file: `${crdDirectory}/${filename}`,
    },
    {
      provider: args.provider,
      parent: this,
    }
  );
});

Versions:

"@pulumi/kubernetes": "^3.7.2",
"@pulumi/pulumi": "^3.13.0",

I have another project doing the same thing that I haven't touched in a while, using @pulumi/pulumi v3.0.0 and @pulumi/kubernetes v3.5.0, which was working fine. Downgrading to those same versions for this still hangs unfortunately.

is it normal for ConfigMaps to being replaced if you change the content?