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
rgw: allow enforcing of maximum requested in listing when possible #33864
Conversation
0364324
to
dcc923a
Compare
Yeah the swift API and therefore clients I've seen expect up to the max container listing limit of a single req (10 000, but configurable), clients should see this value from the /info call. Obivously there is also prefix, marker, end_marker, and reverse which changes potential output, but still that's up to the client to use and understand. (ie, prefix for psudo containers, or marker/end_marker to paginate by some bounds). |
@matthewoliver Thank you for weighing in. I wish this API documentation were more clear: Swift API documentation |
Let me see what I can do re: Swift api on the Swift side :)
…On Wed., 18 Mar. 2020, 1:53 am J. Eric Ivancich ***@***.*** wrote:
@matthewoliver <https://github.com/matthewoliver> Thank you for weighing
in.
I wish this API documentation were more clear: Swift API documentation
<https://docs.openstack.org/api-ref/object-store/?expanded=show-container-details-and-list-objects-detail#show-container-details-and-list-objects>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#33864 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAK3SZ6JTNE4HMUVJZUV5LRH6FIDANCNFSM4LFGYH6A>
.
|
dcc923a
to
a5800aa
Compare
@mattbenjamin This now has both commits. |
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.
please change the base branch from "octopus" to "master"
671e85a
to
0d2efe4
Compare
0d2efe4
to
dfc6d9e
Compare
Some Swift clients assume that the number of items requested in a bucket listing will be returned if possible. This allows the underlying code to enfore that behavior, so Swift can get that behavior, but S3 does not. Signed-off-by: J. Eric Ivancich <ivancich@redhat.com> Signed-off-by: Matt Benjamin <mbenjamin@redhat.com>
dfc6d9e
to
169e408
Compare
we advertise this value of void RGWInfo_ObjStore_SWIFT::list_swift_data(Formatter& formatter,
const ConfigProxy& config,
RGWRados& store)
{
formatter.open_object_section("swift");
formatter.dump_int("max_file_size", config->rgw_max_put_size);
formatter.dump_int("container_listing_limit", RGW_LIST_BUCKETS_LIMIT_MAX); i think we should return the value of |
The challenge is that rgw_max_listing_results is set to 1000, which works well for s3. However, the swift api specifies that 10,000 objects are returned when that many can be returned (see: https://docs.openstack.org/api-ref/object-store/?expanded=show-container-details-and-list-objects-detail). I think technically we'd be OK as long as we "advertise" that value, but that might be problematic with users. But ... clients might assume that without configuration changes they'll get 10,000 back. And ... how would we configure an RGW installation with both s3 and swift users, such that s3 users get 1,000 and swift users get 10,000 entries? |
The config option "rgw_max_listing_results" sets a maximum listing count across a number of operations. Some protocols define a default listing count for some operations. For example, Swift defines a default container listing count of 10,000 items. When this protocol default exceeds the number defined in the config option, the default value should be considered the actual maximum allowed. Signed-off-by: J. Eric Ivancich <ivancich@redhat.com>
169e408
to
dc36295
Compare
QA Results: Any failures are from other sources and do not represent regressions. |
jenkins test make check |
@cbodley : did I address your concerns adequately in #33864 (comment) ? If not, can we talk in order to move this PR forward? |
jenkins test make check |
This pull request has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs for another 30 days. |
This pull request has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs for another 30 days. |
This pull request has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs for another 30 days. |
This pull request has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs for another 30 days. |
This pull request has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs for another 30 days. |
This pull request has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs for another 30 days. |
This pull request has been automatically closed because there has been no activity for 90 days. Please feel free to reopen this pull request (or open a new one) if the proposed change is still appropriate. Thank you for your contribution! |
Some Swift clients assume that the number of items requested in a bucket listing will be returned if possible. This allows the underlying code to enfore that behavior, so Swift can get that behavior, but S3 does not have to.
Tracker: https://tracker.ceph.com/issues/44554