-
Notifications
You must be signed in to change notification settings - Fork 185
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
Update documentation for S3 Express One Zone #667
Conversation
doc/CONFIGURATION.md
Outdated
> [!IMPORTANT] | ||
> Do not set the storage class to `EXPRESS_ONEZONE` as it is a distinct storage class and cannot be set for general purpose | ||
buckets. If you want to use S3 Express One Zone storage class, just specify a directory bucket name when mounting. |
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.
Is this something that could be enforced by code instead of relying on this documentation?
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.
This value is still valid for directory buckets, but it's the same as not setting storage class at all. So, maybe we can just don't allow people to set --storage-class
to EXPRESS_ONEZONE
.
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.
Actually, users also cannot set storage class other than EXPRESS_ONEZONE
for directory buckets. I think the right time to do the validation is after we have resolved the endpoint and know whether this is a directory bucket or not.
Let's do that in a separate PR.
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.
FWIW, I'd caution against setting limits like this that would normally be enforced service-side in S3 but could feasibly be relaxed in the future. In adding this restriction to the client, users are forced to upgrade version to adopt new features (like a new storage class for directory buckets).
Maybe forcing updates has its upsides from maintainers' point of view, but I'd lean against it for now. 😄
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.
What's important is that the user gets clear feedback into what went wrong. If the wrong storage class is set, is the error clear in the Mountpoint logs? Of course we're always limited by the error responses we can send via filesystem APIs.
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.
Currently, users will get InvalidStorageClass
in the logs. But, they only get it on the first write which could be pretty late. I think at least we should do the validation on mount and output a warning message so that they could check their storage class configuration.
8d25357
to
cec21e0
Compare
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.
Thanks Monthon, just a bit more feedback. Most is inline.
On storage classes, can we update the main body to be a bit clearer on default behavior. Mountpoint doesn't specify a storage class and respects the default from S3 - which is STANDARD
for general purpose buckets or EXPRESS_ONEZONE
for directory buckets.
- By default, Mountpoint uses the S3 Standard storage class, which is appropriate for a wide variety of use cases.
+ Mountpoint respects the default storage class from S3 unless otherwise configured, which is appropriate for a wide variety of use cases.
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.
LGTM, thanks @monthonk.
Signed-off-by: Monthon Klongklaew <[email protected]>
Signed-off-by: Monthon Klongklaew <[email protected]>
Co-authored-by: Daniel Carl Jones <[email protected]> Signed-off-by: Monthon Klongklaew <[email protected]>
Signed-off-by: Monthon Klongklaew <[email protected]>
6c5d643
to
c47cd46
Compare
Description of change
Update the configuration and semantics documents to address differences on using Mountpoint with S3 Express One Zone buckets.
Relevant issues: #651
Does this change impact existing behavior?
No, only document updates.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and I agree to the terms of the Developer Certificate of Origin (DCO).