Refer: TimeBound Tokens (https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)

• Update cloudbuild.yaml inside of each of these repos
• Update test-infra/config/jobs/kubernetes-sigs/container-object-storage-interface/

The current readme.md is out of date, and does not give guidelines for new persons interested in the project to easily get started and contribute.

The link is present under the

• Links section:
  - user guide
  - How to write a COSI driver
  - How to make your application COSI-compatible
• Advanced section:
  - Protocols
  - Architecture
  - Internals
• Other:
  - Weekly Meetings

https://github.com/kubernetes-sigs/container-object-storage-interface-api/blob/master/controller/controller.go

• Review the controller design since it was custom built and doesn’t use kube-builder api. We wanted something much simpler and easier to use
• Ensure that there are no deadlocks/race conditions
• Ensure that retries, updates, additions and deletions work as expected of a standard kubernetes controller.

• Getting started
• COSI concepts, architecture and user guide

• Add COSI projects to k8s.io/k8s.gcr.io/images/k8s-staging-sig-storage

Enhancement

Is your feature request related to a problem?/Why is this needed
It would be nice if we could have a library that end-users could import to make it easier for them to parse credentials in the mounted secret.

Describe the solution you'd like in detail
Some utility methods to load secret data into a struct that can be consumed by Go-lang clients of COSI provisioned buckets.

Describe alternatives you've considered
Users could (and probably will) create their own versions of these utility methods, but the idea is to make it easier to switch over to using COSI. If end-users currently use Secrets or environment variables to pass credentials to their applications, we can create a similar DX for COSI.

Additional context

N/A

It's a bit odd for a library like this to depend on viper and have code like NewObjectStorageController which then parses command-line arguments and/or grabs environment variable settings to construct a K8s clientset object.

It's up to consumers of the library to decide which command-line flag parsing library they want to use, how they want to call the flag to point to a KubeConfig file (if any), to maybe read KUBECONFIG from the environment,...

I suggest to change the API to (only) take a clientset which is (somehow) configured correctly by API consumers.

Enhancement

Is your feature request related to a problem?/Why is this needed
Validation for BR to ensure the BC exists
Validation for BAR to ensure the BAC exists
Validation on B/BA for brownfield use cases
Validation for default BC (duplicate defaults should be rejected)

Describe the solution you'd like in detail
An admission controller for the COSI controller

Describe alternatives you've considered
Kubebuilder validation - this works for validating fields in the API, however, we are not able to handle deeper validation e.g., object references.

Additional context

Bucket Class currently use Protocol as a string, we should change this to Protocol Structure for admins to specify specific information.

Do we need to include Name as well as the different protocol options? This makes it so that whenever options are included, users must specify their choice twice: once in Name and once implicitly in the protocol spec. E.g.,

protocol:
  name: s3
  s3:
     blah: stuff

K8s volume claims use a syntax where the option itself implicitly specifies the option desired. E.g.,

volumes:
  - name: myDir
    emptyDir: {}

Does it make sense to follow that pattern for the protocol also? Like below would be an S3 config with no options set.

protocol:
  s3: {}

We need to define unit tests for the controller located in the API. This will automatically also add some core unit tests to the COSI-Controller and Sidecar, where this controller is used.

• API parity: container-object-storage-interface-api and KEP definitions need to be in sync

The provisioner field should be removed from the BAC since it is not relevant.

cc @wlan0

Bug Report

https://github.com/kubernetes-sigs/container-object-storage-interface-api/blob/master/kustomization.yaml#L10 adds an api-approved annotation to all loaded CRDs

The APIs in question have not actually been approved via the k8s API review process

Additionally, using a mixin to automatically add the annotation to all CRDs is not appropriate... it confers approval status on any newly introduced CRDs or updates to CRD manifests without actual review / approve.

As noted in https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/2337-k8s.io-group-protection/README.md#proposal, until the API is approved, a string starting with unapproved can be used as a placeholder

cc @thockin

Enhancement

Is your feature request related to a problem?/Why is this needed

In the future, there might be a need of including additional protocols. There are existing users of object storage platforms that rely on some proprietary protocols:

• OpenStack Object Storage aka. SWIFT - this one is probably most popular.
• EMC Atmos - probably not that popular, proprietary, little bit old.
• CAS - I have not seen it mentioned anywhere besides EMC ECS platform, yet it might be requested by some driver consumers/developers in the future.

Describe the solution you'd like in detail

I would like additional protocols to be introduced to API.

Describe alternatives you've considered

Alternative way is to not have the protocols hardcoded into API and follow the same workflow as CSI drivers.

Additional context

This was firstly discussed on SIG Storage COSI meeting on 2023-03-09.