Hi Christian, It’s good that you pulled me explicitly. So, the __bug__ is in https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/objec... Explanation (reduced version): - normally all the service endpoints are consumed as announced by the service catalog (https://object-store.region.cloud.example.com/swift/v1/AUTH_%(tenant_id)s in your case) - the URL above means that all of the API requests for swift must go to https://object-store.region.cloud.example.com/swift/v1/AUTH_f2bc4bd34567ddc3... - now the /info endpoint of the swift is explicitly NOT including the project_id (AUTH_XXX suffix). Current code calculates the URL to query as mentioned above by reconstructing it from the base domain. There are few similar cases in the SDK when service exposes functions under __non_standard__ url by doing dirty hacks. - Since so far nobody from us was deploying or dealing with cloud having additional element in the path we never seen that as a bug. Solution: - either you remove /swift from your path when deploying swift - or we need to change the mentioned calculation logic by explicitly stripping last 2 elements of the path of the service catalog entry (what seems logical on one side is not guaranteed to be a proper solution either - I have seen wild examples) Regards, Artem
On 4. Aug 2023, at 09:49, Christian Rohmann <christian.rohmann@inovex.de> wrote:
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