[openstack-dev] [swift][ironic][ceph][radosgw] radosgw "support" in python-swiftclient droped for ocata and above

Julia Kreger juliaashleykreger at gmail.com
Wed May 9 21:30:31 UTC 2018


On Wed, May 9, 2018 at 5:10 PM, Casey Bodley <cbodley at redhat.com> wrote:
>
> On 05/09/2018 11:40 AM, Casey Bodley wrote:
>>
>>
>> On 05/09/2018 11:22 AM, Matthew Thode wrote:
>>>
>>> python-swiftclient prior to 3.2.0 seemed to incidentally support radosgw
>>> tempurls.  That is, there was no official support, but it still worked.
>>>
>>> In 3.2.0 (specifically the linked commit(s)) tempurls were validated to
>>> require /v1/account/container/object, which does not work with radosgw
>>> as it expects /v1/container/object.  This means that radosgw tempurls
>>> fail to work, which further means that radosgw will stop working for
>>> things like ironic.

What is the value in the validation of the URL path as such? It seems
like the client shouldn't really care as to the precise format of the
end user supplied URL as long as the server returns the expected
response.

>>> I can see the point that swiftclient should not care about ceph not
>>> fully implementing the swift spec and not supporting the radosgw url
>>> syntax, but it seems like a step back.  If this is not fixed then things
>>> like ironic will not work with radosgw for Ocata and above (as that's
>>> when this change was made).  We'd need to wait for either ceph to fix
>>> this and support the account part of the url (probably just dropping it)
>>> or have people fork python-swiftclient to 'fix' it.
>>>
>>> I'm not sure what the right answer is...

I'm personally -1 to pinning swiftclient as that will introduce
headaches if someone tries to install ironic along side anything that
expects a newer client or vise-versa.

I agree it seems like a step back, to which I'm curious about the
value of having the check. The forth option is for ironic to abruptly
drop all related code and support for radosgw temp urls, but that too
would be a setback and negative for OpenStack in general.



More information about the OpenStack-dev mailing list