<div dir="ltr">Hi Akihiro,<div><br></div><div>Thanks for summarizing.</div><div>Just to make it written, networking-odl gate is suffering from the same problem.</div><div><br></div><div>Regards</div><div>Lajos</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Akihiro Motoki <<a href="mailto:amotoki@gmail.com">amotoki@gmail.com</a>> ezt írta (időpont: 2020. febr. 20., Cs, 15:45):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
networking-bagpipe gate is broken now due to its dependencies.<br>
The situation is complicated so I am summarizing it and exploring the<br>
right solution.<br>
<br>
# what happens now<br>
<br>
Examples of the gate failure are [1] and [2], and the exact failure is<br>
found at [3].<br>
It fails due to horizon dependency from networking-bgpvpn train<br>
release (horizon>=14.0.0<17.0.0) and the upper-constraints.txt master<br>
(horizon==18.0.0).<br>
The neutron team has not released a beta for ussuri, so<br>
requirements.txt tries to install networking-bgpvpn train which has<br>
capping of horizon version.<br>
The capping of horizon in networking-bgpvpn was introduced in [6] and<br>
we cut a release so it started to cause the failure like this.<br>
<br>
We've explored several workarounds to avoid it including specifying<br>
horizon in networking-bagpipe, specify horizon in required-projects in<br>
networking-bagpipe and dropping networking-bgpvpn in requirements.txt<br>
in networking-bagpipe, but all of them do not work.<br>
<br>
# possible solutions<br>
<br>
I am thinking two options.<br>
The one is to cut a beta release in neutron stadium for ussuri.<br>
The other is to uncap horizon in networking-bgpvpn train and release it.<br>
<br>
I believe both work but the first one would be better as it is time to<br>
release beta for Ussuri.<br>
Discussing it in the IRC, we are planning to release beta soon.<br>
(ovn-octavia-provider is also waiting for a beta release of neutron.)<br>
<br>
# Side notes<br>
<br>
Capping dependencies in stable branches is not what we usually do.<br>
Why we don't do this was discussed in the mailing list thread [4] and<br>
it is highlighted in [5].<br>
<br>
Thanks,<br>
Akihiro Motoki (irc: amotoki)<br>
<br>
[1] <a href="https://review.opendev.org/#/c/708829/" rel="noreferrer" target="_blank">https://review.opendev.org/#/c/708829/</a><br>
[2] <a href="https://review.opendev.org/#/c/703949/" rel="noreferrer" target="_blank">https://review.opendev.org/#/c/703949/</a><br>
[3] <a href="https://zuul.opendev.org/t/openstack/build/3bc82305168b4d8cad7e4964c7207e00/log/job-output.txt#1507" rel="noreferrer" target="_blank">https://zuul.opendev.org/t/openstack/build/3bc82305168b4d8cad7e4964c7207e00/log/job-output.txt#1507</a><br>
[4] <a href="http://lists.openstack.org/pipermail/openstack-discuss/2019-November/thread.html#11229" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-discuss/2019-November/thread.html#11229</a><br>
[5] <a href="http://lists.openstack.org/pipermail/openstack-discuss/2019-November/011283.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-discuss/2019-November/011283.html</a><br>
[6] <a href="https://review.opendev.org/#/c/699456/" rel="noreferrer" target="_blank">https://review.opendev.org/#/c/699456/</a><br>
<br>
</blockquote></div>