On 03/08/2023 17:32, Jeremy Stanley wrote:
On 2023-08-03 17:09:29 +0200 (+0200), Christian Rohmann wrote:
we use Ceph RadosGW (Quincy release) to provide Swift as part of an OpenStack cloud. [...]
While I don't have an answer for your question, I did want to clear up any potential misunderstanding. Please be aware that Ceph RadosGW is not Swift, it is a popular non-OpenStack alternative to using actual Swift, and supplies a partial replica of Swift's user-facing API (but with a substantially different backend implementation). Ceph RadosGW does not have feature-parity with Swift, lacking a number of Swift's features and sometimes having much different behaviors or performance even for the features it attempts to replicate.
So just to reiterate, Ceph RadosGW isn't Swift any more than Swift's S3-API is S3. It's merely a compatibility shim, and you shouldn't expect it to work the same way Swift does.
Thanks Jeremy for clarifying this. Honestly I was pretty aware of that fact, but did not want to NOT mention it. Regarding the particular error I am seeing, this seems to then cause the OpenstackSDK to fail on discovering the "Swift caps" at https://opendev.org/openstack/openstacksdk/src/commit/88fc0c2cf6269dd2d3f862... with the exception being: "No Info found for None: Client Error for url: https://object-store.region.cloud.example.com/info, Not Found" (I added a line to log the exception, which otherwise is just silently ignored). When issuing a GET to "https://object-store.region.cloud.example.com/swift/info" the caps are returned:
{"bulk_delete":{},"container_quotas":{},"swift":{"max_file_size":5368709120,"container_listing_limit":10000,"version":"17.2.6","policies":[{"default":true,"name":"default-placement"}],"max_object_name_size":1024,"strict_cors_mode":true,"max_container_name_length":255},"tempurl":{"methods":["GET","HEAD","PUT","POST","DELETE"]},"slo":{"max_manifest_segments":1000},"account_quotas":{},"staticweb":{},"tempauth":{"account_acls":true}}%
So to me it's not (yet) about Ceph vs. original Swift, but rather about the discovery logic in keystoneauth1 to find the correct base-URL from the endpoints, which is "/swift" instead of "/" in my case. But that could very well be also a possible setup for Swift, right? And isn't that what the endpoint list is all about? Telling clients the correct URLs for services? And why does this (using /swift) seem work without issue when doing other actions like "container list"? I violently added Artem to CC, since he wrote the wrote the project cleanup code for object storage https://review.opendev.org/c/openstack/openstacksdk/+/853015 Regards (and sorry Artem for dragging you into this thread), Christian