Skip to content

Question: Standard parameters for BucketClass and BucketAccessClass #244

Closed as not planned

Description

@kvaps

Hello, seaweedfs-cosi-driver and cozystack maintainer here.

I'm working on implementing additional features in our COSI driver and have a question about the intended usage of the parameters field in BucketClass and BucketAccessClass.

Looking at the spec, I see that parameters are passed as opaque map<string,string> to the driver:

  • BucketClass.parameters → DriverCreateBucketRequest.parameters
  • BucketAccessClass.parameters → DriverGrantBucketAccessRequest.parameters

I have two use cases:

1. Creating buckets with S3 Object Lock enabled

I want to create buckets with Object Lock (WORM protection). Should this be a BucketClass parameter?

apiVersion: objectstorage.k8s.io/v1alpha1
kind: BucketClass
metadata:
  name: immutable-storage
driverName: seaweedfs.objectstorage.k8s.io
deletionPolicy: Retain
parameters:
  objectLockEnabled: "true"  # Is this the right place?

2. Granting read-only access to buckets

I want to grant read-only access to existing buckets. Should this be a BucketAccessClass parameter?

apiVersion: objectstorage.k8s.io/v1alpha1
kind: BucketAccessClass
metadata:
  name: readonly-access
driverName: seaweedfs.objectstorage.k8s.io
authenticationType: Key
parameters:
  accessPolicy: "readonly"  # Is this the right place?

Questions

  1. Is this the intended usage of parameters in BucketClass and BucketAccessClass?
  2. Are there any plans to standardize common parameters across drivers (similar to how CSI has standard parameters like csi.storage.k8s.io/fstype)?
  3. Are there any existing drivers that implement similar functionality that I could reference?

For context, this is similar to how StorageClass parameters work in CSI:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: local
provisioner: linstor.csi.linbit.com
parameters:
  linstor.csi.linbit.com/storagePool: data
  linstor.csi.linbit.com/layerList: storage

Thank you!

Activity

  1. BlaineEXE commented on Jan 29, 2026

    @BlaineEXE
    Member

    Thanks for the clear questions @kvaps .

    If it helps, at a high level, the architecture and usage of COSI is intended to closely mirror that of CSI. If you are familiar with CSI driver development, you should find quite a bit of overlap with COSI.

    1. BucketClass and BucketAccessClass are absolutely intended to be used as you described. I also think you've paired the right options for the right Classes.

      In general, if an option is set per-bucket, the BucketClass is probably the right place. If an option is set per-user, the BucketAccessClass is probably the right place.

    2. As far as standardization, we have talked about this a little. It gets complex for portability, but we do plan to add some recommended parameter names/descriptions so that different drivers can share some configurations that aren't appropriate for COSI's first-class APIs which need to be portable across myriad permutations of platform, protocol, driver, and backend. I would imagine these to be things like objectstorage.k8s.io/maxObjects, objectstorage.k8s.io/maxSize. COSI likely won't do any internal handling of parameters, just pass them through to drivers, but shared naming could still benefit the community as a whole I think. If you have recommendations for "shareable" parameter definitions, I'll be happy to make a note of them.

    3. This example is slightly different, but Ceph-COSI has parameters that specify the namespace and name of the k8s Secret that contains credential information for COSI to create buckets/users in the Ceph RGW backend: https://github.com/ceph/ceph-cosi/blob/master/examples/bucketclass.yaml

      Linode's COSI driver defines a read/write permissions option which more closely matches your scenarios: https://github.com/linode/linode-cosi-driver/blob/main/examples/linode-objectstorage.BucketAccessClass.yaml

    Also worth noting, the COSI v1alpha2 API includes Read/Write access mode as a first-class API. While this isn't relevant for your v1alpha1 API, it might help you design for the present and future. The new KEP's PR is here for your reference if desired: kubernetes/enhancements#4599

  2. k8s-triage-robot commented on Apr 29, 2026

    @k8s-triage-robot

    The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

    This bot triages un-triaged issues according to the following rules:

    • After 90d of inactivity, lifecycle/stale is applied
    • After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
    • After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

    You can:

    • Mark this issue as fresh with /remove-lifecycle stale
    • Close this issue with /close
    • Offer to help out with Issue Triage

    Please send feedback to sig-contributor-experience at kubernetes/community.

    /lifecycle stale

  3. added
    lifecycle/staleDenotes an issue or PR has remained open with no activity and has become stale.
    on Apr 29, 2026
  4. k8s-triage-robot commented on May 29, 2026

    @k8s-triage-robot

    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:

    • After 90d of inactivity, lifecycle/stale is applied
    • After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
    • After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

    You can:

    • Mark this issue as fresh with /remove-lifecycle rotten
    • Close this issue with /close
    • Offer to help out with Issue Triage

    Please send feedback to sig-contributor-experience at kubernetes/community.

    /lifecycle rotten

  5. added
    lifecycle/rottenDenotes an issue or PR that has aged beyond stale and will be auto-closed.
    and removed
    lifecycle/staleDenotes an issue or PR has remained open with no activity and has become stale.
    on May 29, 2026
  6. k8s-triage-robot commented on Jun 28, 2026

    @k8s-triage-robot

    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:

    • After 90d of inactivity, lifecycle/stale is applied
    • After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
    • After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

    You can:

    • Reopen this issue with /reopen
    • Mark this issue as fresh with /remove-lifecycle rotten
    • Offer to help out with Issue Triage

    Please send feedback to sig-contributor-experience at kubernetes/community.

    /close not-planned

  7. kubernetes-prow commented on Jun 28, 2026

    @kubernetes-prow
    Contributor

    @k8s-triage-robot: Closing this issue, marking it as "Not Planned".

    Details

    In response to this:

    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:

    • After 90d of inactivity, lifecycle/stale is applied
    • After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
    • After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

    You can:

    • Reopen this issue with /reopen
    • Mark this issue as fresh with /remove-lifecycle rotten
    • Offer to help out with Issue Triage

    Please send feedback to sig-contributor-experience at kubernetes/community.

    /close not-planned

    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-sigs/prow repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    lifecycle/rottenDenotes an issue or PR that has aged beyond stale and will be auto-closed.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions