Create v1alpha2 with bucket quotas #66
Conversation
This makes no changes to the spec except to appropriately modify the version name. Signed-off-by: Blaine Gardner <[email protected]>
Focus initially on quotas applied to all buckets created from a BucketClass. This means that a storage admin may specify limits that apply to every user of the BucketClass. Users do not have self-service control over bucket quotas beyond their ability to select amongst some number of BucketClasses. Signed-off-by: Blaine Gardner <[email protected]>
k8s-ci-robot
added
the
cncf-cla: yes
|
Welcome @BlaineEXE! |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: BlaineEXE The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
needs-ok-to-test
|
Hi @BlaineEXE. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
k8s-ci-robot
added
the
size/XL
|
Because this creates v1alpha2, it looks like a lot of changes as a whole. But the 2nd commit shows the actual extent, which is currently quite small. I don't foresee this being finished yet, but I want to start having initial conversations before addressing things like Bucket status items showing what quotas are in place. |
|
/hold This needs more design discussions before merging. |
k8s-ci-robot
added
the
do-not-merge/hold
There was a problem hiding this comment.
Any plans to tie up with https://kubernetes.io/docs/concepts/policy/resource-quotas/#storage-resource-quota like PVCs and storageclasses
|
|
||
| // Quotas defines optional quotas applied to all buckets created from this Bucket Class. | ||
| // +optional | ||
| Quotas BucketQuotas `json:"quotas,omitempty"` |
There was a problem hiding this comment.
IMO the BucketClass should have quota based on no of buckets as well
There was a problem hiding this comment.
Is that something that can be controlled via Kubernetes RBAC?
There was a problem hiding this comment.
I believe, based on Xing's input, the appropriate way for admins to limit the number of buckets that users can request is via resource quotas. To my understanding, this would allow admins can limit the number of BucketRequests that users or service accounts are allowed to create, and that would then limit the number of buckets in the backend.
It seems best to me to use Kubernetes authorization and quota mechanisms as much as possible so that COSI is not implementing unnecessary complexity. This follows the school of thought that systems are generally easier for users to configure when there is only a single means of accomplishing any given goal.
I do think the suggestion is a relevant point and germane to the discussion. I think we should clarifying in the COSI design how admins are intended to limit the number of buckets themselves.
| // Parameters is an opaque map for passing in configuration to a driver | ||
| // for granting access to a bucket | ||
| // +optional | ||
| Parameters map[string]string `json:"parameters,omitempty"` |
There was a problem hiding this comment.
There should be some sort of quota offering in BucketAccessClass as well to restrict users, say if the same bucket is shared among different users which has a limit of 10Gb. If one user consumes 9Gb and otherone will have only 1Gb access remaining
There was a problem hiding this comment.
This design is specifically only for bucket quotas. Rook users have given feedback that they want bucket quotas, but they seem to not have strong desires for access/user-level quotas right now. Given that, and in the interest of making small, incremental changes, I have intentionally omitted BucketAccess quotas from the proposal.
|
@BlaineEXE Can you work on a design doc as this is a new feature? |
|
In Kubernetes, there is a way to specify the number of CRs. Maybe that is useful as well. See an example here: https://github.com/kubernetes-csi/external-snapshotter#setting-quota-limits-with-snapshot-custom-resources |
|
Closing this after discussion today. Likely, there is no need for v1alpha2. We can add changes to the v1alpha1 types freely (unlike beta/stable).
|
|
Closing this, as likely a v1alpha2 won't be proposed, instead opting to modify the v1alpha1 api as allowed by "alpha" state. |
…atch-1 Update Makefile
…atch-1 Update Makefile
Copy v1alpha1 -> v1alpha2 with no changes. Then...
Add optional quotas to BucketClass:
Focus initially on quotas applied to all buckets created from a
BucketClass. This means that a storage admin may specify limits that
apply to every user of the BucketClass. Users do not have self-service
control over bucket quotas beyond their ability to select amongst some
number of BucketClasses.