[stable][requirements][neutron] Capping pip in stable branches or not

Bernard Cafarelli bcafarel at redhat.com
Fri Dec 11 09:20:35 UTC 2020


now that master branches have recovered from pip new resolver use, I
started looking at stable branches status. tl;dr for those with open
pending backports, all branches are broken at the moment so please do not

Thinking about fixing gates for these branches, older EM branches may be
fine once the bandit 1.6.3 issue [1] is sorted out, but most need a fix
against the new pip resolver.

pip has a flag to switch back to old resolver, but this is a temporary one
that will only be there for a few weeks [2]

>From a quick IRC chat, the general guidance for us was always to leave pip
uncapped, and the new resolver issues are actually broken requirements.

But looking at master fixes, these indicate large and complicated changes
on requirements and lower-contraints. Neutron fix [3] required a few major
linter bumps and major version bumps in l-c. I guess it may be doable as
victoria backport, but this will be messy for previous branches.

ovn-octavia-provider is a scarier example [4], from stable point of view
the change by itself does not look good for backport, even just for

Also, in master, some fixes were possible by bumping versions on
dependencies, but how to fix them if the max possible versions have broken
deps themselves?

So, how do we proceed to fix stable gates? Ideas and feedback will be most

[2] http://pyfound.blogspot.com/2020/11/pip-20-3-new-resolver.html
[3] https://review.opendev.org/c/openstack/neutron/+/766000

Bernard Cafarelli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20201211/d0dbed5c/attachment.html>

More information about the openstack-discuss mailing list