Does Pulumi have a concept of "unowned" resources?...
# announcements
o
Does Pulumi have a concept of "unowned" resources? e.g.: I have a storage class that might exist in Kubernetes, called
ssd
. A stack that deploys with limited permissions to a namespace cannot and should not own that storage class, because storage classes are a global resource. So I'd like to conditionally choose the storage class for a volume in a statefulset with logic like:
Copy code
const ssdClass = new k8s.storage.v1.StorageClass(
  'ssd', 
  { metadata: { name: 'ssd' }, ... },
  { readonly: true }, // or loadOnly, or load, or whatever, I just want to get the resource that currently exists in Kubernetes that matches the spec I've provided. if it differs, I'd like this to return undefined
);
// ... in the spec for statefulSet
   storageClass: ssdClass ? ssdClass.metadata.name : undefined`
Edit: Actually, come to think of it that API won't work,
new
will always return an instance of a class. So perhaps a static method on the Kubernetes resource, like:
k8s.storage.v1.StorageClass#read
that returns an
Output<k8s.storage.v1.StorageClass | undefined>
?
c
@orange-policeman-59119 have you looked at
k8s.storage.v1.StorageClass.get(...)
?
o
whoaaa
TY!
That looks like it returns a concrete StorageClass, no
Output
, what happens if the named storage class doesn't exist?
c
get
will fail
o
ah
Is there a non-failing
get
?
or, lol, do I try catch it? will that work in the pulumi context or will an error propagate outside of an exception
c
not right now — can you tell me a bit more about the scenario?
is the storage class created by the cloud provider?
o
I have a Pulumi stack that I want to deploy to a namespace, which means I should be able to deploy it using a service account that has limited permissions to that namespace. In this case, another stack or a cluster admin may have manually created an
ssd
storage class, and if that exists we ought to use that for persistence. If not, we should fall back to the default by leaving it undefined.
And yes, the storage class could be created by the cloud provider. GKE does not create an SSD class by default, just a standard HDD backed one. I think Azure creates a standard and a premium SSD backed class (it's been a minute since I've used it), and EKS doesn't define any by default.