[sdk] openstacksdk 0.99.0 breaks swift object header setting

Artem Goncharov artem.goncharov at gmail.com
Fri Jun 3 07:08:26 UTC 2022

> On 2. Jun 2022, at 22:52, Clark Boylan <cboylan at sapwetik.org> wrote:
> On Thu, Jun 2, 2022, at 12:54 PM, Artem Goncharov wrote:
>> Thanks Jeremy, will try to analyze the trace.
>> This is not too extensive, but better then silent pin without 
>> possibility to even notice that.
>> I see that there are generally not enough deep tests for Openstack 
>> driver in Zuul since mostly issues appear in Prod.  I will to try to 
>> invest some time there.
> We do functional testing against a devstack cloud. Unfortunately, as previously mentioned every cloud is just sufficiently unique that there are always corner cases that devstack can't catch. In general what we are able to test is that we can upload an image to devstack then boot that image and ssh into it. But then different clouds support different image upload methods and networking and even hypervisors. We do our best but once you get to the variety of clouds in the wild there is a lot more opportunity to find bad assumptions.

Right. I didn’t want to say there is no testing. I mean in Zuul you have knowledge of the corner cases you face and they need to be included in tests to guarantee we do not break. But actually now I think it would be a real big benefit to everybody to include knowledge of those cases including corresponding tests into the SDK so that others can also benefit from that. Those who rely on SDK should just work no matter which particular cloud they are working with.

This brings me slowly to other point. Our dream of real interoperability has not taken off. What is the sense of any certification if this does not save us even in pretty simple scenarios: provision host with custom image or upload object to object_store with CORS on? As a person who is responsible on our cloud for passing this certification I say openly: at the moment this is as good as useless at all. There are tests, and yes, sometimes it is even a challenge to pass those. But if they are not even able to guarantee us interoperability here this is not worth of effort.
With this knowledge we can say that there is not a single OpenStack public cloud out there. They are all “based on OpenStack”.


>> Artem
>> ----
>> typed from mobile, auto-correct typos assumed
>> ----
>> On Thu, Jun 2, 2022, 21:47 Jeremy Stanley <fungi at yuggoth.org> wrote:
>>> On 2022-06-02 21:12:33 +0200 (+0200), Artem Goncharov wrote:
>>> [...]
>>>> I listen to complains carefully, and that is the reason for R1.0
>>>> not to exist as of now.
>>> [...]
>>> It's probably also worth pointing out, from a user experience
>>> perspective, that we anticipated backward-incompatible changes in
>>> 1.0.0 and so merged an openstacksdk<1 pin in nodepool's
>>> requirements.txt file. Unfortunately, instead the
>>> backward-incompatible changes were released as 0.99.0 so when the
>>> container images for our launchers updated we started getting
>>> another error back from all of the Rackspace regions we're using
>>> (traceback attached).
>>> I'm happy to file a bug report on that if nobody has beaten me to
>>> it, but further diagnostics will probably have to wait until after
>>> summit travel since we've rolled back to 0.61.0 for now.
>>> -- 
>>> Jeremy Stanley

More information about the openstack-discuss mailing list