I’m guessing I would need the models from ‘cert-manager.io/v1alpha2’ to start with. Do these exists?

Running Pulumi up shows “+ 34 to create” with loads of errors (“creating failed error: … already exists”). Also removing the new ConfigFile line does not seem to remove the stuff from the k8s

Hm,… could that be because I manually ran those that yaml and the resources are not managed by Pulumi?

I’m getting confused about everything regarding cloud state storage. I find the following issues and/or PRs: • Backend setting in project config (https://github.com/pulumi/pulumi/pull/2813) • Persist filestate backend URL in Pulumi.<stackname>.yml (https://github.com/pulumi/pulumi/issues/2996) • Project name in stack identity inconsistent between backends (https://github.com/pulumi/pulumi/issues/2522) • Using S3 backend with multiple projects is unpleasant (https://github.com/pulumi/pulumi/issues/2814) This is a bit of a mess. The first two issues seem to contradict: is a backend URL project or stack specific? Also, if each project can have a different backend, how can project B which has a StackReference to A find the state backend of A? On top of that, how can Pulumi be logged in into different backends?

Q: before creating a cluster a provider obviously isn’t valid and until

doctl kubernetes cluster kubeconfig save $CLUSTER_NAME

has been run (manually) instructions such as

new kubernetes.yaml.ConfigFile("cert-manager", {file: ...}

seem to fail (error: unable to load Kubernetes client configuration from kubeconfig file: invalid configuration: no configuration has been provided). Is there a recommended way around that?

Anyone here tried to create k8s cluster in circle ci ? an inspiration about the use case is https://circleci.com/blog/continuous-integration-for-salesforce-applications/ I have a question !

Could anyone try to reproduce this issue on Linux or MacOs? https://github.com/pulumi/pulumi-kubernetes/issues/949 Is only Windows affected?

i'm installing cert-manager via yaml and i have

const certManager = new k8s.yaml.ConfigFile(yamlUrl, {}, {provider});
const dependsOn = certManager.resources.apply((resources: any): any => Object.values(resources));
const CLUSTER_ISSUER_YAML = `...`; // uses http01
const clusterIssuer = new k8s.yaml.ConfigGroup('cluster-issuer', {yaml: CLUSTER_ISSUER_YAML}, {provider, dependsOn});

so that the

ClusterIssuer

isn't installed until after everything else is. now i'm also adding a secret so that i can do a

dns01

solver using digitalocean. is there a way to add the secret to

dependsOn

? basically, to merge two `apply`s? or would i have to create the secret with the first

dependsOn

, and then do a

pulumi.all

to merge the two `ConfigGroup`s' resources?

anyone know of any godaddy providers already available? if not I was going to take a stab at converting

terraform-godaddy

a bit later today

It’s not that Pulumi work or doesn’t work, it’s just that I know too little on how stuff works.

I think some people might take your "Don’t rely on Pulumi for destroying things." comment as suggesting that Pulumi is unreliable, hence my response. :)

Yeah, I can see that, I am using Pulumi because it’s more reliable than me, sorry if it came across like that.

In my years using pulumi I’ve never seen it accidentally fail to delete resources.

I have. It had issues with Cloudfront because that process is slow. Issues with S3 where if the bucket wasn’t empty. It’s not Pulumis fault, but it did put us in a weird state that other stuff couldn’t be deleted as well (Roles, iAM users). had to manually edit state for that.

The issue isn’t Pulumi, terraform has the same issues ofc. Proper tagging + AWS console is easier and more obvious.

hmm, I don’t think I understand the specific scenario. in any event, pulumi doesn’t manage ALBs on your behalf in the situation described. If they are left over this is almost certainly an EKS issue.

this is true for both

Service

and

Ingress

cc @late-printer-99022

Yeah, I’ve suggested in the past that maybe Pulumi should take over that. ALB is integral and doing it outside is such a shame and error prone. Especially with weakly typed yamls.

sorry—to clarify, the ALB is created on your behalf by EKS, when you use a Kubernetes resource like

Service

. If Pulumi interceded on your behalf it would almost certainly break something.

The kube controller in general expects to have total control of this resource.

happy to explain more in a thread—I was the original author of the kube stuff so I know it really well.

@creamy-potato-29402 Yeah, but it should be a different approach than using the ALB ingress controller. Setting up ALB with pulumi and point it to a serice or an ingress.

I think I've found a bug and reported it here. https://github.com/pulumi/pulumi/issues/3748 If someone could give it a once over for anything obviously stupid (always a possibility!), it would be appreciated.

you can definitely use other ingress controllers. Contour provides Envoy-based load balancing, and nginx-ingress does, well, what it says on the box.

in general this is totally pluggable.

not sure I understand this second comment though.

The second comment is how it works today with the ALB ingress CRD. That’s the selling point of it, is that it bypasses k8 and connects ALB directly by keep tracking the pods and nodes and connecting the ALB directly. The approach I am suggesting is a little bit more “inferior” since it goes ALB -> K8 -> Nodes -> Pods

Is there a way to get pulumi version programmatically, thinking of using it for tagging AWS resources.

Also, is there a way to set configs programatically?