I'm incrementally trying get sonarqube deployed using their helm chart via pulumi/c#. When I supply the values in a yaml file with hardcoded values on the command line, it works successfully. When I try to use pulumi, with the following code I receive the following error:

new ChartArgs
{
    Repo = "oteemocharts",
    Chart = "sonarqube",
    Namespace = namespaceName,

    Values =
        {
            {  "image", new { tag = "8.3-community" } },
            {
                "postgresql",
                new
                {
                    enabled = false,
                    postgresqlServer = postgresqlServer.Fqdn,
                    postgresqlPassword = postgresqlPassword.Result,
                    postgresqlDatabase = postgresqlDatabase.Name,
                    postgresqlUsername = Output.Format( $"{postgresqlServer.AdministratorLogin}@{postgresqlServer.Name}" )
                }
            },

Diagnostics:
  kubernetes:helm.sh:Chart (helm-sonarqube):
    error: Pulumi.ResourceException: coalesce.go:195: warning: destination for postgresqlDatabase is a table. Ignoring non-table value sonarDB
    coalesce.go:195: warning: destination for postgresqlPassword is a table. Ignoring non-table value sonarPass
    coalesce.go:195: warning: destination for postgresqlDatabase is a table. Ignoring non-table value sonarDB
    coalesce.go:195: warning: destination for postgresqlPassword is a table. Ignoring non-table value sonarPass
    Error: template: sonarqube/templates/secret.yaml:14:66: executing "sonarqube/templates/secret.yaml" at <b64enc>: wrong type for value; expected string; got map[string]interface {}

Anyone have ideas what I'm doing wrong?

Is there a recommended way to refactor the resource hierarchy when one of the resources that moves is a provider? Specifically, try moving around an

eks.Cluster

(eg. from top level into a component resource). It’ll work almost, (with

aliases: [{parent: pulumi.rootStackResource}]

), but you can’t move the

nodeAccess

configmap, because it can’t find it’s provider (it’s trying to use the new provider that you don’t have yet). I can open a bug if this isn’t tracked yet, I ran into problems with refactoring providers multiple times already. Possibly the problem is that the new provider doesn’t act like a dependency on which you have to wait. Or that the reference to the provider itself isn’t aliased (ie. the alias for the provider isn’t propagated to the dependents so that you could reference the old provider through the new urn).

vaguely remembered the bug, here it is: https://github.com/pulumi/pulumi/issues/3979

Hi there, I'm noticing that old replica sets aren't being cleaned up after a successful deployment. I think it kinda makes sense as you'd want to be able to roll back to and old one on failure, but is there a standard way of cleaning these up?

Hello again Kubernetes peeps...

This fragment of Pulumi-code that uses the nginx Ingress Controller Helm chart is working but it does not use my k8sDnsLabel in the PublicIP that is created in Azure by the IngressController. I'm wondering if any of you have any insights.

const env = pulumi.getStack(); // reference to this stack
const stackId = `dave/aks/${env}`;
const aksStack = new pulumi.StackReference(stackId);
const k8sDnsName = aksStack.getOutput("k8sDnsName"); // <-- This is "identity-auth-dev"

// Deploy ingress-controller using helm to AKS Cluster
const options = {
    chart: "nginx-ingress-controller",
    namespace: "kube-system",
    repo: "bitnami",
    values: {
        annotations: {
            "<http://service.beta.kubernetes.io/azure-dns-label-name|service.beta.kubernetes.io/azure-dns-label-name>": "identity-auth-dev"
        },
        resources: { requests : {memory: "150Mi", cpu: "100m"}},
        serviceType: "LoadBalancer",
        nodeCount: 1,
    }
};
const nginxIngress = new k8s.helm.v3.Chart("nginx", options, {provider: k8sProvider });

I don't think this a Pulumi problem other than me doing something incorrectly.

has anyone here used the pulumi crosswalk stacks Supposed to be production ready, maybe best practice?

Hello there, I have a weird issue with a chart, I’m using https://github.com/bitnami/charts/tree/master/bitnami/postgresql-ha, everything works fine so far, but each time I

pulumi up

a

Secret

created by the chart (namely the

pgpool

one) keeps getting replaced each time for a

~data

diff reason. Anyone would know the reason and how to make it permanent please ? (Never had this issue with any other chart I use)

I'm talking with someone about https://cdk8s.io/ and it sounds a lot like pulumi - but pulumi requires storing somewhere state, whereas this doesn't. What / why does pulumi need to store in case of kubernetes, if "kubernetes already stores state in etcd"?

Hi. We are using managed kubernetes on AKS.

azure.containerservice.KubernetesCluster

resource provides the property

kubeAdminConfigRaw

which we feed directly in the k8s provider like so:

let cluster = new k8s.Provider(name, {kubeconfig: aks.kubeAdminConfigRaw,})

This works perfectly fine except due to this conservative diffing https://github.com/pulumi/pulumi-kubernetes/blob/master/provider/pkg/provider/provider.go#L270 every change on the AKS resource will trigger a complete recreation of all resources that use this k8s provider instance. Note, that the kubeconfig is mostly a means of authentication, not actually something stateful itself ... Does anyone have the same problem? Any solutions? 🙂

Hi there, I have a newbie question regarding Helm deployments with Pulumi. I created a helm resource with the official spinnaker helm chart. I adapt the values and the with the values I create Configmaps. The first deployment with Pulumi was successfully. When I make changes in the Configmaps I see the proper Pulumi resources are being replaced. But it seems after the replace there is no upgrade to the helm chart executed. I need this because there is a K8s job triggered by post-upgrade and this job isn’t running but is strongly required. Can anyone help me out?

Question unrelated to Pulumi, but does anyone here have any experience with the pure Java Kubernetes API? (https://javadoc.io/doc/io.kubernetes/client-java-api/7.0.0/index.html). Context: I’m trying to create a PersistentVolume and PersistentVolumeClaim that I can use later on as a volume in a pod running Pulumi for local state storage. I could use some examples… (It’s the maximum I want to do without Pulumi. 😉 )

Hi, i'm trying to import a

Deployment

which I believe has the same spec, but pulumi is giving me a diff where the entire

containers

array is going to be deleted. When I dump out my deployment object in the code, it has the containers array filled in. I'm guessing i'm wrong and the state doesn't match for the import. Is this a pulumi bug where it can't diff the array contents?

@white-balloon-205 or whoever has most recently touched pulumi/kubernetes, I think there might be a regression or bug in Pulumi 1.14 (Kubernetes provider 1.6.0) where: When changing env vars in a Deployment as in this thread: https://pulumi-community.slack.com/archives/CRFURDVQB/p1589939594223900?thread_ts=1585519243.027400&cid=CRFURDVQB 1. Deployment resources are marked for "replace", not "update" despite having no changes incompatible with an update/PATCH 2.

deleteBeforeReplace

is not used, causing the deployment to fail because deployment names are unique within a namespace and the creation fails I have two questions: 1. Is there a way to force the Kubernetes provider to perform an "update"? 2. Are there best practices for maintaining large lists of env vars to avoid bizarre updates like the one shown in the link above, where inserting an env var "out of order" resulted in a bizarre diff?

General kubernetes question, kubeconfig should be treated as a secret right? e.g. stored encrypted, restrict access etc..

Anyone else have deprecation warnings disappear after an update of the kubernetes plugin? It's as though

suppressDeprecationWarnings

is on by default now.

I try to modify the default namespace in my kubernetes cluster using

ConfigFile

and an actual manifest. Running the manifest with

kubectl apply -f

works, but it fails through pulumi. The error message is: error: resource default was not successfully created by the Kubernetes API server : namespaces "default" already exists So I guess pulumi does something else than

kubectl apply

. Is there a way to run a manifest that updates a namespace? The part in the code I have now looks like this (F#)

ConfigFile("proxy_inject",
        ConfigFileArgs(
            File = input "manifests/proxy_inject.yaml"
        )) |> ignore

More questions coming 🙂. Is there a way to a service name that doesn't add the extra unique characters to the string? Making a POC in .NET and here I would like to set the Uri for the service in the

appsettings.json

file in the frontend app, but that doesn't work since pulumi adds some characters. I guess one way could be to get the name from the environment somehow instead.

When deploying to kubernetes I've had a couple of deploys sort of being stuck with "[1/2] Waiting for app ReplicaSet be marked available" and then failing. Is this a known issue?

Just FYI, I created a twitter thread that’s all about our k8s provider. Should be a good primer if you’re new to Pulumi: https://twitter.com/levi_blackstone/status/1265798769242550272?s=20

Is the recommended way of managing migrations with Kubernetes still

initContainers

? Would something like https://github.com/pulumi/pulumi-kubernetes/pull/633 help with waiting for a migration

Job

to finish before deploying other resources?

Does anyone know if I need to install the AWS EFS CSI driver to be able to create an EFS storage class? EBS seems to work without installing the EBS CSI driver.

This appears to indicate that you to: https://www.pulumi.com/blog/persisting-kubernetes-workloads-with-amazon-efscsi-volumes-using-pulumi-sdks/.

Also curious why that article doesn't use the CSI driver helm better for long term maintainance. Does that Pulumi code do something different than the efs csi driver helm chart?

it's almost a year old, so practices have probably changed since then

That is frustrating... 1 year is not very long. Is there up to date documentation?

unfortunately 1 year seems to be a long time in the k8s community. Regarding your original question, EBS works without a driver because it's (currently) in tree: https://github.com/kubernetes/kubernetes/tree/323f34858de18b862d43c40b2cced65ad8e24052/pkg/volume/awsebs although there are tentative plans to remove it at some point in the future. So yes, you will have to install the EFS CSI driver

Hi, I followed the basic tutorial to start a k8s cluster using Pulumi (creating the cluster and then adding a NGINX deployment on it). This works fine (except when using a non-default Amazon credentials, although I'm not sure why). The problem I have is that after all the steps complete, I couldn't access the public IP of the nginx deployment from my browser. I tried updating the code using that of another tutorial (which sets up an nginx to redirect the pulumi.github.io page), and all the steps worked correctly but I still couldn't see the page from outside. Could someone indicate what permissions I should change?