-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
[Bucket API] KEP updates for API review #2813
Conversation
b2ee7c9
to
6ff0006
Compare
@wlan0 can you link the KEP in the title of this PR and description? |
BucketAccessClassName string | ||
} | ||
|
||
Status BucketRequestStatus { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typo I assume. Should be BucketAccessRequestStatus
// for creating the bucket | ||
// +optional | ||
Parameters map[string]string | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no API linkage between Bucket
and BucketAccess
. So will COSI be making GET (or cache) calls to fetch all BAs for a given B?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, I haven't yet seen 1:n mapping relations defined between the COSI resources. Is it 1 BR per B? One BAR per BA? Many BAs per B? etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Deletion is the only reasons we need this list. However, this cascading deletion behavior can be achieved using owner references, where deleting a BR deletes the B and all other associated BA's.
Is there any other reason for us to get this information? If not, then we should be fine
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, I haven't yet seen 1:n mapping relations defined between the COSI resources. Is it 1 BR per B? One BAR per BA? Many BAs per B? etc.
The resources are loosely coupled, for instance, similar to how pods and nodes are related. Whenever a stronger coupling is needed, we directly reference the related object in the referring object.
…for all, and introduce referencePolicy for future cross-NS bucket sharing
…e for bucketAccess -> bucketClaim -> bucket references
…/non-namespaced resource
PRR Is good for alpha. For beta promotion, having a solid story for cluster-admins to observe cluster-wide status will be important /approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: deads2k, msau42, wlan0 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/milestone v1.25 |
/lgtm |
No description provided.