You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Allow usage of kubernetes controlled Buckets and BucketAccesses instead of manually provided secrets via Container Object Storage Interface (COSI).
Expected behavior
COSI stands for Container Object Storage Interface. It is similar to the CSI spec, but instead of targeting the Block and File storage, it targets the Object storage - e.g. AWS S3, MinIO, Dell EMC ObjectScale and other. It defines few new concepts like Buckets, BucketClaims, BucketClasses, BucketAccesses and BucketAccessClasses.
Buckets - represents a Bucket (or its equivalent) in the storage backend. Generally, it should be created only in the brownfield provisioning scenario, otherwise is automatically created by controller. Think of PersistentVolume / PV but for Object storage.
BucketClasses - represents a class of Bucket resources with similar characteristics. It should be created by cluster administrator. Think of StorageClass / SC but for Object storage.
Sample manifest:
apiVersion: objectstorage.k8s.io/v1alpha1kind: BucketClassmetadata:
name: my-bucketclassdriverName: cosi.dellemc.comdeletionPolicy: Deleteparameters:
param1: value
BucketAccesses - represents a access request to generate a Secret, that will allow you to access Object storage.
And few other are under the development, most importantly MinIO.
Possible fixes
Until the COSI is in alpha (observe spec) it should stay as optional feature - especially when there is no COSI Driver for AWS and MinIO publicly available.
The text was updated successfully, but these errors were encountered:
Summary
Allow usage of kubernetes controlled
Buckets
andBucketAccesses
instead of manually provided secrets via Container Object Storage Interface (COSI).Expected behavior
COSI stands for Container Object Storage Interface. It is similar to the CSI spec, but instead of targeting the Block and File storage, it targets the Object storage - e.g. AWS S3, MinIO, Dell EMC ObjectScale and other. It defines few new concepts like
Buckets
,BucketClaims
,BucketClasses
,BucketAccesses
andBucketAccessClasses
.Buckets
- represents a Bucket (or its equivalent) in the storage backend. Generally, it should be created only in the brownfield provisioning scenario, otherwise is automatically created by controller. Think ofPersistentVolume
/PV
but for Object storage.Sample manifest:
BucketClaims
- represents a claim (or request) to provision a Bucket. Think ofPersistentVolumeClaim
/PVC
but for Object storage.Sample manifest:
BucketClasses
- represents a class ofBucket
resources with similar characteristics. It should be created by cluster administrator. Think ofStorageClass
/SC
but for Object storage.Sample manifest:
BucketAccesses
- represents a access request to generate aSecret
, that will allow you to access Object storage.Sample manifest:
BucketAccessClasses
- represents a class ofBucketAccess
resources with similar characteristics. It should be created by cluster administrator.Sample manifest:
Workflow
Full video by Jiffin Tony Thottan: https://www.youtube.com/watch?v=lff2c7n5s6Q
Right now there are few COSI Drivers that can provision the storage:
And few other are under the development, most importantly MinIO.
Possible fixes
Until the COSI is in
alpha
(observe spec) it should stay as optional feature - especially when there is no COSI Driver for AWS and MinIO publicly available.The text was updated successfully, but these errors were encountered: