Open Stack

Thanks Akihiro for the summary!

I think "possible solution 1" could work. Nevertheless I've pushed a 
revert [7] for the capping patch [6], since that is now completely 
unnecessary (given that horizon is added in upper constraints of Train).

It is good to communicate the proper way of fixing these issues [4], 
especially since that changed recently as in the past e.g. neutron and 
horizon were not allowed to be added to upper-constraints [8].

Thanks,

Előd

[7] https://review.opendev.org/#/c/708865/
[8] https://review.opendev.org/#/c/631300/



On 2020. 02. 20. 15:41, Akihiro Motoki wrote:

> Hi,
>
> networking-bagpipe gate is broken now due to its dependencies.
> The situation is complicated so I am summarizing it and exploring the
> right solution.
>
> # what happens now
>
> Examples of the gate failure are [1] and [2], and the exact failure is
> found at [3].
> It fails due to horizon dependency from networking-bgpvpn train
> release (horizon>=14.0.0<17.0.0) and the upper-constraints.txt master
> (horizon==18.0.0).
> The neutron team has not released a beta for ussuri, so
> requirements.txt tries to install networking-bgpvpn train which has
> capping of horizon version.
> The capping of horizon in networking-bgpvpn was introduced in [6] and
> we cut a release so it started to cause the failure like this.
>
> We've explored several workarounds to avoid it including specifying
> horizon in networking-bagpipe, specify horizon in required-projects in
> networking-bagpipe and dropping networking-bgpvpn in requirements.txt
> in networking-bagpipe, but all of them do not work.
>
> # possible solutions
>
> I am thinking two options.
> The one is to cut a beta release in neutron stadium for ussuri.
> The other is to uncap horizon in networking-bgpvpn train and release it.
>
> I believe both work but the first one would be better as it is time to
> release beta for Ussuri.
> Discussing it in the IRC, we are planning to release beta soon.
> (ovn-octavia-provider is also waiting for a beta release of neutron.)
>
> # Side notes
>
> Capping dependencies in stable branches is not what we usually do.
> Why we don't do this was discussed in the mailing list thread [4] and
> it is highlighted in [5].
>
> Thanks,
> Akihiro Motoki (irc: amotoki)
>
> [1] https://review.opendev.org/#/c/708829/
> [2] https://review.opendev.org/#/c/703949/
> [3] https://zuul.opendev.org/t/openstack/build/3bc82305168b4d8cad7e4964c7207e00/log/job-output.txt#1507
> [4] http://lists.openstack.org/pipermail/openstack-discuss/2019-November/thread.html#11229
> [5] http://lists.openstack.org/pipermail/openstack-discuss/2019-November/011283.html
> [6] https://review.opendev.org/#/c/699456/
>