<div>Are we going to keep some job not using the archive, to make sure we don't break people using packages from LTS? Maybe just periodic/non-voting would be enough to keep it working on older packages.</div><div><br><div class="gmail_quote"><div>On Mon, Apr 3, 2017 at 4:07 PM Clark Boylan <<a href="mailto:cboylan@sapwetik.org">cboylan@sapwetik.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br class="gmail_msg">
<br class="gmail_msg">
One of the major sets of issues currently affecting gate testing is<br class="gmail_msg">
Libvirt stability. Elastic-recheck is tracking Libvirt crashes for us<br class="gmail_msg">
and they happen frequently [0][1][2]. These issues appear to only affect<br class="gmail_msg">
Ubuntu Xenial (and not Trusty or CentOS or Fedora) and after talking in<br class="gmail_msg">
#openstack-nova it is clear that Libvirt isn't interested in debugging<br class="gmail_msg">
such an old version of Libvirt (1.3.1). And while it isn't entirely<br class="gmail_msg">
clear to me which exact version would be acceptable to them the Ubuntu<br class="gmail_msg">
Cloud Archive (UCA) does publish a much newer Libvirt (2.5.0).<br class="gmail_msg">
<br class="gmail_msg">
I have pushed a change to devstack [3] to enable using UCA which pulls<br class="gmail_msg">
in new Libvirt and mostly seems to work. I think we should consider<br class="gmail_msg">
switching to UCA as this may fix our Libvirt problems and if it doesn't,<br class="gmail_msg">
we will be closer to a version of Libvirt that upstream should be<br class="gmail_msg">
willing to fix.<br class="gmail_msg">
<br class="gmail_msg">
This isn't the most straightfoward switch as UCA has a different repo<br class="gmail_msg">
for each OpenStack release. libvirt-python is sensitve to the underlying<br class="gmail_msg">
library changing; it is backward compatible but libvirt-python built<br class="gmail_msg">
against older libvirt won't work against new libvirt. The result is a<br class="gmail_msg">
libvirt-python wheel built on our wheel mirror does not work with UCA.<br class="gmail_msg">
On the positive side both the OpenStack puppet modules and OpenStack<br class="gmail_msg">
Ansible are using UCA with their deployment tooling so this should get<br class="gmail_msg">
us closer to what people are using in the wild.<br class="gmail_msg">
<br class="gmail_msg">
After some thought I think my preferred method of rolling this out would<br class="gmail_msg">
be to blacklist libvirt-python from our wheel mirror building entirely<br class="gmail_msg">
and force installs to happen from source so that we are base Xenial and<br class="gmail_msg">
$UCA_version independent (local testing of these builds show it only<br class="gmail_msg">
takes a few seconds). Then have specific jobs (like devstack) explicitly<br class="gmail_msg">
opt into the UCA repo appropriate for them (if any). This last bit is<br class="gmail_msg">
from feedback from OpenStack Ansible that having the base images be<br class="gmail_msg">
fairly clean is desirable, but it would also be hard to know which<br class="gmail_msg">
version of UCA is appropriate for our Xenial images (this likely differs<br class="gmail_msg">
based on the job).<br class="gmail_msg">
<br class="gmail_msg">
Now its entirely possible that newer Libvirt will be worse than current<br class="gmail_msg">
(old) Libvirt; however, being closer to upstream should make getting<br class="gmail_msg">
fixes easier. Would be great if those with a better understanding of<br class="gmail_msg">
Libvirt could chime in on this if I am completely wrong here.<br class="gmail_msg">
<br class="gmail_msg">
Finally it is worth noting that we will get newer packages of other<br class="gmail_msg">
software as well, most notably openvswitch will be version 2.6.1 instead<br class="gmail_msg">
of 2.5.0.<br class="gmail_msg">
<br class="gmail_msg">
Any other thoughts or ideas?<br class="gmail_msg">
<br class="gmail_msg">
[0] <a href="http://status.openstack.org/elastic-recheck/#1646779" rel="noreferrer" class="gmail_msg" target="_blank">http://status.openstack.org/elastic-recheck/#1646779</a><br class="gmail_msg">
[1] <a href="http://status.openstack.org/elastic-recheck/#1643911" rel="noreferrer" class="gmail_msg" target="_blank">http://status.openstack.org/elastic-recheck/#1643911</a><br class="gmail_msg">
[2] <a href="http://status.openstack.org/elastic-recheck/#1638982" rel="noreferrer" class="gmail_msg" target="_blank">http://status.openstack.org/elastic-recheck/#1638982</a><br class="gmail_msg">
[3] <a href="https://review.openstack.org/451492" rel="noreferrer" class="gmail_msg" target="_blank">https://review.openstack.org/451492</a><br class="gmail_msg">
<br class="gmail_msg">
Thank you,<br class="gmail_msg">
Clark<br class="gmail_msg">
<br class="gmail_msg">
__________________________________________________________________________<br class="gmail_msg">
OpenStack Development Mailing List (not for usage questions)<br class="gmail_msg">
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" class="gmail_msg" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br class="gmail_msg">
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class="gmail_msg">
</blockquote></div></div>