I'm not far from answering this question myself, as soon as I deploy this next set of artifacts, but how does

k8s.scope.resource.get

behave if the resource specified is absent? Is it a fallible operation? I ask because I would like to deploy an operator in one (shared) place, which defines CRDs. Then, if and only if the CRDs exist, in other stacks use them to deploy additional components. Example: Prometheus Operator chart defines a ServiceMonitor CRD, the service monitor object defines a set of targets to scrape for metrics. Other stacks should deploy ServiceMonitor resources in their namespaces, but only if the CRD exists.

you can query apiserver for installed CRDs

There's a way to do that with Pulumi, or no?

Hmm, I think the idea was the the

.get()

operation should fail if the resource doesn’t exist, but doesn’t seem to be the case (it just no-op’d). I’ll check with the team to see if that’s a bug

with valid kubeconfig you can always fallback to plain kubernetes client or even rest client , query

/api

to get a list of registered apiversions, all installed CRDs are also there

Apparently this is a known bug: https://github.com/pulumi/pulumi-terraform/issues/262

@best-xylophone-83824 thanks, I am aware of that. I wanted to know if it was possible to "try" to query for a remote resource using the Pulumi provider API, which would be more general and not require shelling out.

So the answer is “that’s the intent”, but it’s not working right now

Based on the bug report, it looks like the intent is to throw an error if the resource doesn't exist, but the current behavior is my desired behavior

No need for shelling out, keep using same language , can be all within same pulumi preview/up run

I know, thank you Maxim.

Based on the bug report, it looks like the intent is to throw an error if the resource doesn't exist, but the current behavior is my desired behavior

Curious to understand this better. The current behaviour doesn't raise an error - but also doesn't communicate the failure in any generally discoverable way (as well as violating the typing that is promised). If this did throw an error, you could

try/catch

it to do your work in cases where it is not available. Would that accomplish your needs?

Yeah, that would be fine

That is technically an alternative here - to return

| undefined

- but I think the ergonomics of that are actually possible more awkward for normal usage?

yeah, I think that's right