[sdk][devstack] openstacksdk-functional-devstack job failing on stable branches

Sylvain Bauza sbauza at redhat.com
Fri Jan 28 10:49:37 UTC 2022


Le mer. 26 janv. 2022 à 15:28, Artem Goncharov <artem.goncharov at gmail.com>
a écrit :

> Hi
>
> On 26. Jan 2022, at 14:35, Sean Mooney <smooney at redhat.com> wrote:
>
> On Wed, 2022-01-26 at 13:26 +0000, Jeremy Stanley wrote:
>
> On 2022-01-26 09:00:05 +0100 (+0100), Slawek Kaplonski wrote:
> [...]
>
> Those tests are available only in master branch: [1] and they not
> exists in e.g. stable/xena [2].
>
> I'm not sure how those jobs are defined exactly but my guess is
> that on those stable branches where it fails it runs openstacksdk
> from master branch. So either it should be changed and proper
> stable branch of the openstacksdk should be used there or we
> should skip those tests when API extension in neuron is not
> present.
>
> [...]
>
> I find it intriguing that the SDK has stable branches at all. Isn't
> the goal that the latest version of the SDK be able to interface
> with multiple versions of OpenStack services, new and old? If we
> don't test that the current SDK code works with Neutron from Xena,
> then that opens it up to growing serious problems for users.
>
> ya that seam odd to me too.
> i would expect sdk to be release independent and work simialr to tempest
> where master sdk should be useable with all stable branches.
>
> Having the SDK or tests work out what features are expected to work
> sounds like the only sensible solution.
>
>
> Well, actually it should be working. Cause of absence of real tests this
> way I can not guarantee it will work in every case, but we do our best to
> keep it this way (and most of the tests are checking whether feature is
> available or not).
>
> Honestly I have no clue why it evolved this way and therefore can’t really
> comment on that. Maybe (just maybe) there was something from the Debian (or
> other distro) packaging pov (stable, not-stable, etc) that somehow leaded
> to this setup. Otherwise there is absolutely no possibility to limit which
> version of sdk need to go into which older distro. And since i.e. ansible
> and openstackclient depend on the sdk things are getting even more
> interesting. Sdk in this sense is comparable with keystoneauth lib (and
> actually depend on it). So once we say there are no stable branches of sdk
> anymore we open even worse can of worms.
>
> Since we are currently anyway in a phase of big rework in sdk I would say
> addressing tests that do not work on older branches can be done as well.
>

FWIW, we recently discussed on #openstack-nova about this [1] and the
consensus was that we should try to avoid as much as possible any attempt
to test stable releases of Nova against any stable branch of the SDK.

I haven't seen yet any bug report, does anyone know about it ?

As our conclusion was that we would refrain pulling stable branches of the
SDK, we'll need to make the job non-voting on our repositories as it holds
merging backports.

More to come in the next hours,
-Sylvain

[1]
https://meetings.opendev.org/irclogs/%23openstack-nova/%23openstack-nova.2022-01-28.log.html#t2022-01-28T10:42:31


> Artem
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220128/d7e45e61/attachment.htm>


More information about the openstack-discuss mailing list