Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support for max-objects and max-size bucket quotas/policies #28

Open
BlaineEXE opened this issue Oct 26, 2023 · 0 comments
Open

support for max-objects and max-size bucket quotas/policies #28

BlaineEXE opened this issue Oct 26, 2023 · 0 comments

Comments

@BlaineEXE
Copy link
Contributor

Several Rook users have expressed interest in per-bucket quotas. Specifically max objects and max size quotas.

In COSI's upstream design planning, we've come to the agreement that these 2 quotas don't fit into the main COSI API. The major cloud providers don't provide these types of quotas, and so the interface wouldn't be portable. Instead, vendors like Ceph should use the opaque parameters on Bucket(Access)Classes to choose these quotas.
 
Because some Rook users also use Noobaa, it would be nice if COSI objects (BucketClass, for this design) can be portable between Ceph-COSI and Noobaa-COSI. I've done some pre-planning with Noobaa to reach an agreed-upon spec.

kind: BucketClass
# ...
parameters:
  maxObjectsPerBucket: <int>
  maxSizePerBucket: <string, parsable to Kubernetes resource.Quantity>

Kubernetes resource.Quantity spec: https://pkg.go.dev/k8s.io/[email protected]/pkg/api/resource#Quantity

The Noobaa team prefers to use the maxSizePerBucket as defined here rather than the config Ceph uses underneath which is max_size_kb. Kilobytes are very granular when many of these quotas will be Gigabytes for large users, so the resource.Quantity representation is preferred.

We should be sure to have clear error messaging for users when this quantity doesn't parse correctly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant