Le mer. 26 janv. 2022 à 15:28, Artem Goncharov artem.goncharov@gmail.com a écrit :
Hi
On 26. Jan 2022, at 14:35, Sean Mooney smooney@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.202...
Artem