adding the

libc6-compat

package fixed it, it provides the

libpthread

dep

every other 'pulumi preview' i do on VSTS build agent uninstalls pulumi/azure.... and i have no idea why lol. it always reinstalls it the next time

2018-10-01T18:14:59.7947559Z removed 1 package and updated 5 packages in 6.163s

https://github.com/npm/npm/issues/17379 ah /vsts# npm --version 5.6.0

Re: Alpine - see https://github.com/pulumi/pulumi/issues/1986 where this is being discussed.

is there a non-interactive mode that doesn’t apply the changes? similar to a terraform plan?

2018-10-01T19:07:13.3692281Z + kubernetes:core:Secret tls-sctl-nginx creating 1 error. error: Plan apply failed: Secret in version "v1" cannot be handled as a Secret: v1.Secret.Data: decode base64: illegal base64 data at input byte 0, error found in #10 byte of

nooooooo

interesting, the kubernetes provider wont catch spec errors. e.g. both will “work” even though the first has

volumeMounts

and

resources

scoped wrong

spec: {
      containers: [{
      name: coin.name,
      image: "<http://978526999579.dkr.ecr.eu-west-1.amazonaws.com/|978526999579.dkr.ecr.eu-west-1.amazonaws.com/>"+xyz.name }],
      resources: {
        requests: {
          memory: "2Gi",
          cpu: "500m"
        },
        limits: {
          memory: "4Gi",
          cpu: "1"
        }
      },
      volumeMounts: {
        name: "data", 
        mountPath: "/data"
      }
    }

spec: {
      containers: [{
        name: coin.name,
        image: "<http://978526999579.dkr.ecr.eu-west-1.amazonaws.com/|978526999579.dkr.ecr.eu-west-1.amazonaws.com/>"+xyz.name,
        resources: {
          requests: {
            memory: "2Gi",
            cpu: "500m"
          },
          limits: {
            memory: "4Gi",
            cpu: "1"
          }
        },
        volumeMounts: [{
          name: "data",
          mountPath: "/data"
        }]
      }]
    }

@steep-keyboard-19086 No, they posted a deposit (Not Customer Deposit) to an A/R account.

just had a weird kubernetes thing where it sat at 'creating ingress' literally forever - and there were already 5 of them - i deleted all the existing ones and it completed immediately.

is there a workaround for https://github.com/pulumi/pulumi-kubernetes/issues/162 ?

i might be misreading the issue, but from my testing i have been unable to use pulumi outputs in my charts

Are there any existing third party Pulumi modules people would recommend to check out? Any custom components etc? An

awesome-pulumi

github repo would be great 😛 Otherwise, I guess the pulumi/examples repo is the best place to get inspiration?

@fresh-flag-12765 Great example from @stocky-spoon-28903 here for both use and inspiration: https://github.com/jen20/pulumi-aws-vpc

Ohh perfect, great example. The power of libraries is going to be such a killer feature (at least, in my humble opinion).

hey folks, have a little issue here. We use GKE (GCP + k8s). Now inspired by https://github.com/pulumi/examples/blob/master/gcp-ts-gke/cluster.ts#L27 I’ve written a utility funtion with this signature:

const getK8sProviderByClusterName: (clusterName: string) => k8s.Provider

. It basically creates a k8s provider simply by passing a clustername (of an existing cluster - it will not magically create a new one) to it (and project id and zone are taken from the gcp config). The cluster is typically not defined itself in the stacks which use that utility function, so in order to get the cluster I’m using

Cluster.get(...)

. The idea was to avoid having my team members to “correctly” configure their kubeconfig, set the right context etc. etc. but instead make the deployment target explicitly configured in code by using only the

clusterName

. The problem I’m suddenly facing is that when anything non-substantial in the cluster changes, pulumi also wants to recreate (replace) the k8s provider and ALL the resources that have been previously created by that provider. Non-substantial changes in my case for example is that one of the node-pools scaled down by 1 instance. Even though I don’t use the node pool count at all to generate the k8s provider, pulumi wants to recreate it from scratch. Any advise on how to avoid this kind of problem? From my understanding Pulumi tracks here the dependency between the cluster and the k8s provider and because the k8s provider depends on the cluster any cluster changes will recreate the k8s provider. Is there any way to disable this auto-magic dependency tracking in this instance?

Hi all 👋 I’m trying to create a custom authorizer for an AWS API Gateway. I’ve been following an example in the Terraform documentation - https://www.terraform.io/docs/providers/aws/r/api_gateway_authorizer.html - but I’m coming unstuck when trying to define a role policy that references a lambda. Thread:

I'm having the same problem I had yesterday.... pulumi's convinced that it needs to create a new k8s ingress resource (it already made one). I've deleted alllll ingresses but pulumi just sits there at "creating..." and times out after about 10 minutes.

i did pulumi destroy to just start again cos i wasnt getting anywhere...

Diagnostics: kubernetes:certmanager.k8s.io:ClusterIssuer: lets-encrypt-issuer error: Plan apply failed: Server is unable to handle certmanager.k8s.io/v1alpha1, Kind=ClusterIssuer

it created it!

info: panic: runtime error: invalid memory address or nil pointer dereference [signal 0xc0000005 code=0x0 addr=0x0 pc=0x128929d] goroutine 62 [running]: github.com/pulumi/pulumi-kubernetes/pkg/provider.checkpointObject(0xc042004fd0, 0x0, 0xc042701bd0)

gosh

global: global info: warning: Cluster failed to report its version number; falling back to 1.9%!(EXTRA bool=false)

heh

somethings broken

From the blog, our new project and stack templating UIs in the service and CLI: https://blog.pulumi.com/building-new-pulumi-projects-and-stacks-from-templates

I don’t think it’s interesting enough