We're using Pulumi to build a Kubernetes cluster on GCP, with the Istio integration enabled (https://cloud.google.com/istio/docs/istio-on-gke/overview). Istio on GKE creates all the necessary k8s resources to run Istio, we do not have a reference to them in Pulumi. In order to setup TLS and configure domains, the docs recommend us to edit the existing resources. We can do this with Pulumi via an import, but (if I've understood correctly) this means we cannot build our setup with a single

pulumi up

. Instead, we need one

pulumi up

where the

import

simply reflects the existing resource, and then another one where we edit the code to change the resource. We've verified this multi-stage flow works, but it feels clunky (currently we have to manually edit the code between the first and second pulumi up). Are there any tricks we can use to combine into a single stage? One thought was that maybe there is a variable that denotes whether or not the resource is already referenced. Then we could run pulumi twice, and use a switch statement to distinguish the two cases. Feels very hacky though.

Yes - there is currently no great way to do this - we still thinking about how best to support this sort of thing in a clean desired-state model. The state with two updates approach is something I’ve seen used - though it is indeed a bit “hacky”. We’ve also used effectively shelling out to

kubectl apply

as another workaround for this for example in the Pulumi-EKS package. This also is not ideal - but has worked reasonably well. But it’s not “simple”. See https://github.com/pulumi/pulumi-eks/blob/master/nodejs/eks/cni.ts#L151. We have a few issues opened tracking ideas on how to support this in a more first-class way.

The shell trick is neat. But this would apply the update every time?

The ways it's used in that linked code snippet is as part of a dynamic provider - so it's done only in the Create step - this is not trivial at all - but is possible.