Closed omniproc closed 3 weeks ago
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/reopen
/remove-lifecycle rotten
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
/kind feature
What happened:
When a
ResourceQuota
/LimitRange
is created it is enforced per namespace.Those are namespaced resources that affect any
StorageClass
used for the given namespaceWhat you expected to happen: We'd like to implement limits per
StorageClass
to make sure vSphere backing datastores are not over-provisioned. Or, to put it differently: we'd like to have a method to make sure the effect on the datastore is the same as ifResourceQuota
would be calculated cross-namespaces.How to reproduce it (as minimally and precisely as possible):
StorageClass
ResourceQuota
/LimitRange
shown aboveAnything else we need to know?:
This is probably a feature vSphere admins are very interested it as it enables control of datastore usage which is currently not possible. Since this is a vSphere CSI specific request I guess it would make most sense to implement it as a
parameter
of thecsi.vsphere.vmware.com
StorageClass
object. The responsibility of the admin configuring theStorageClass
would be to ensure that the total space defined by this parameter of allStorageClass
pointing to the same vSphere datastore doesn't go above the vSphere datastore capacity. I do not believe that there should more logic to this since whatever additional check you might implement it would all break when the same backing datastore is used by another K8s cluster. The scope of this really is:StorageClass
is configured by a different persona then PV/PVC. Usually that persona has access to the backing datastore and is responsible for it's proper function. Let's call this persona "vSphere admin" for the sake of this discussion.StorageClass
can not consume more then what the "vSphere admin" allowed. Else they could break the datastore, possibly not only affecting their own workload but also other workload that resides on that datastore.Environment: