Object Storage Support (COSI)

[wlan0]

Enhancement Description

• One-line enhancement description (can be used as a release note): Natively support object storage in Kubernetes alongside file and block storage
• Kubernetes Enhancement Proposal: object bucket provisioning #1383
• Primary contact (assignee): @wlan0
• Responsible SIGs: sig-storage
• Enhancement target (which target equals to which milestone):
  • Alpha release target (1.25)
  • Beta release target (1.30)

https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1979-object-storage-support

[wlan0]

/sig storage

[wlan0]

/assign wlan0

[k8s-ci-robot]

@wlan0: You must be a member of the kubernetes/milestone-maintainers GitHub team to set the milestone. If you believe you should be able to issue the /milestone command, please contact your and have them propose you as an additional delegate for this responsibility.

In response to this:

/milestone 1.20

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.

[xing-yang]

I see there's already another issue opened here: #1593
Can we close one of them?

[wlan0]

Could you please close the other one: #1593

Looks like john created that project before he left the group

[xing-yang]

Sure. I closed the other issue.

[kikisdeliveryservice]

@xing-yang @wlan0

Just confirming this is indeed for 1.21 not 1.20?

Thanks!
Kirsten

[xing-yang]

@kikisdeliveryservice,

Yes, we are targeting Alpha in 1.21. In 1.20, we are planning to get the KEP merged as Provisional status and coding will happen in repos under kubernetes-sigs. That's why we still have 1.20 as milestone for the KEP.

[kikisdeliveryservice]

@xing-yang understood - thank you for the clarification! I'll update the sheet to reflect the alpha in 1.21 goal so we don't start pinging you for the 1.20 cycle on this issue 😄

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[xing-yang]

/remove-lifecycle stale

[jrsapi]

Greetings @wlan0 @xing-yang,

This is Joseph v 1.21 enhancement shadow. For the enhancement to be included in the 1.21 milestone, it must meet the following criteria:

The KEP must be merged in an implementable state
The KEP must have test plans Done
The KEP must have graduation criteria Done
The KEP must have a production readiness review

Also starting 1.21, all KEPs must include a production readiness review. Please make sure to take follow all the instructions and update the KEP to include this.

Thank you!

[jrsapi]

@wlan0 @xing-yang

Enhancements Freeze is 2 days away, Feb 9th EOD PST

Please make sure to work on PRR questionnaires and requirements and get it merged before the freeze. For PRR related questions or to boost the PR for PRR review, please reach out in slack #prod-readiness

Any enhancements that do not complete the following requirements by the freeze will require an exception.

[DONE] The KEP must be merged in an implementable state
[IN PROGRESS] The KEP must have test plans
[DONE] The KEP must have graduation criteria
[IN PROGRESS] The KEP must have a production readiness review

[annajung]

Hi @wlan0 ,

Enhancements Freeze is now in effect.

Unfortunately, KEP for this enhancement does not meet all the required criteria. If you wish to be included in the 1.21 Release, please submit an Exception Request as soon as possible.

/milestone clear

[k8s-triage-robot]

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

This bot triages issues and PRs 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 or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[k8s-triage-robot]

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

This bot triages issues and PRs 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 or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

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

/lifecycle rotten

[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

[k8s-ci-robot]

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

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/test-infra repository.

[xing-yang]

/remove-lifecycle rotten

[mickeyboxell]

Hello @wlan0 👋, Enhancements team here.

Just checking in as we approach enhancements freeze on 02:00 UTC Friday 9th February 2024 / 18:00 PDT Thursday 8th February 2024:.

This enhancement is targeting for stage beta for v1.30 (correct me, if otherwise)

Here's where this enhancement currently stands:

• KEP readme using the latest template has been merged into the k/enhancements repo.
• KEP status is marked as implementable for latest-milestone: 1.30. KEPs targeting stable will need to be marked as implemented after code PRs are merged and the feature gates are removed.
• KEP readme has up-to-date graduation criteria
• KEP has a production readiness review that has been completed and merged into k/enhancements. (For more information on the PRR process, check here).

For this KEP, we would just need to update the following:

• The latest-milestone and stage should be updated to 1.30 and beta in the kep.yaml file.
• The production readiness review should be completed and updated with the information for the targeting stage beta.
• KEP status is marked as implementable for latest-milestone: 1.30.

The status of this enhancement is marked as at risk for enhancement freeze. Please keep the issue description up-to-date with appropriate stages as well. Thank you!

[mickeyboxell]

@xing-yang to confirm, is the plan to defer this to a later release?

[xing-yang]

Hi @mickeyboxell,

We'll continue to work on it, but we are not targeting v1.30. Thanks!

cc @wlan0 @BlaineEXE

[salehsedghpour]

/milestone clear

[pierreozoux]

Hi

we have a simple, custom, home made bucket object with a controller that reconcile on a minio cluster.
We'd like to move towards a standard, and we'd like to know the status of this KEP? Is it alpha? Can we start an implementation on this and give feedback?

Thanks!

[BlaineEXE]

@pierreozoux, COSI is currently in v1alpha1, and we are working toward v1beta1. The KEP design doc as approved for v1alpha1 can be found here: https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1979-object-storage-support

We currently expect few to no breaking changes between API v1alpha1 and v1beta1. Please start an implementation if you desire. We are seeking user/developer feedback.

For more Q&A, please seek us out on the Kubernetes slack's #sig-storage-cosi channel link.

[haoxiaoci]

@BlaineEXE @wlan0
I have some doubts regarding the COSI API design and I would appreciate your help with these questions:

1. When I create a BucketClaim, I would like to be able to specify the name of the bucket, which is not an existing bucket but rather one that is created alongside the creation of the BucketClaim.
   it seems like that COSI API current alpha version does not support this feature. will this feature be supported in the current alpha or in subsequent versions?
2. Suppose I have two BucketClaims (bc1 and bc2), which means I have created two new buckets(baclass-xxxbucket1, baclass-xxxbucket2). and then I create a BucketAccess (ba1), which means i have created one user (ba-xxx), how can I then grant user ba-xxx access to these two buckets(baclass-xxxbucket1, baclass-xxxbucket2)?
   i am not sure that the current COSI API design support this feature. if current COSI API design support this, I would be more than happy to learn how to implement it. and if current COSI API design does not support this, will this feature be supported in the current alpha or in subsequent versions?

[shanduur]

@haoxiaoci Regarding 2:
You do not necessarily create new user in a BucketAccess. This depends completely on the driver implementation, but the consensus is to create new access credentials which are bound only to a single bucket.

[BlaineEXE]

Regarding 1:
This cannot be done, because it is a security risk. If users are allowed to arbitrarily specify bucket names, they could easily be able to "hijack" the same-named bucket from another COSI bucket or from a non-COSI bucket in the backend.

Regarding 2:
I have it on my todo list to design and implement a multi-bucket:single-access workflow, but it's not ready yet.

[haoxiaoci]

@BlaineEXE
Regarding 1:
i see... it should be concerned.
Regarding 2:
glad to know that it's on todo list. however, when is it expected to be completed and released? because we're considering how to integrate COSI

[BlaineEXE]

glad to know that it's on todo list. however, when is it expected to be completed and released? because we're considering how to integrate COSI

It will take time. The design must be approved by sig-storage members (outside of COSI wg), and then we must implement it. I hope that it'll be done before end of year.