<div dir="ltr">Hey Clark,<div><br></div><div>re Xen in CI:<br></div><div>that's interesting - kolla ansible users request Xen support from time to time and we just spread our hands.</div><div>We also do not have complete IPv6 support for Xen due to the lack of a testbed.</div><div>If there was effort to provide Xen-enabled nodes in CI, I would be glad to hear of results.</div><div><br></div><div>Kind regards,</div><div>Radek</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">pt., 18 paź 2019 o 12:02 Sean Mooney <<a href="mailto:smooney@redhat.com">smooney@redhat.com</a>> napisał(a):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, 2019-10-17 at 12:32 -0700, Clark Boylan wrote:<br>
> On Thu, Oct 17, 2019, at 9:33 AM, melanie witt wrote:<br>
> > On 10/17/19 08:39, Matt Riedemann wrote:<br>
> > > This was brought up in the nova meeting today [1] as:<br>
> > > <br>
> > > "Do we have a particular stance on features to the libvirt driver for <br>
> > > non-integration tested configurations, e.g. lxc [2] and xen [3], meaning <br>
> > > if they are trivial enough do we just say the driver's quality warning <br>
> > > on startup is sufficient to let them land since these are changes from <br>
> > > casual contributors scratching an itch?"<br>
> > > <br>
> > > We agreed to move this to the mailing list.<br>
> > > <br>
> > > We don't have tempest jobs for the libvirt+lxc or libvirt+xen <br>
> > > configurations (Citrix used to host 3rd party CI for the latter) and for <br>
> > > the changes referenced they are from part-time contributors, minor and <br>
> > > self-contained, and therefore I wouldn't expect them to build CI jobs <br>
> > > for those configurations or stand up 3rd party CI.<br>
> > > <br>
> > > There are cases in the past where we've held features out due to lack of <br>
> > > CI, e.g. live migration support in the vSphere driver. That's quite a <br>
> > > bit different in my opinion because (1) it's a much more complicated <br>
> > > feature, (2) there already was 3rd party CI for the vSphere driver and <br>
> > > (3) there is a big rich corporation maintaining the driver so I figured <br>
> > > they could pony up the resources to make that testing happen (and it <br>
> > > eventually did).<br>
> > > <br>
> > > For these other small changes are we OK with letting them in knowing <br>
> > > that the libvirt driver already logs a quality warning on startup for <br>
> > > these configs [4]? In this case I am but wanted to ask and I don't think <br>
> > > this sets a precedent as not all changes are equal.<br>
> > <br>
> > I'm OK with this and I think the quality warning sets an appropriate <br>
> > expectation. As I mentioned in the meeting, my opinion is I think <br>
> > sufficiently trivial changes are fine on this basis. I also wouldn't try <br>
> > to set a hard precedent because each thing needs review on whether it's <br>
> > "trivial", but I support a spirit of accepting simple changes without <br>
> > requiring full blown 3rd party CI, given the quality warnings we have <br>
> > for the configs mentioned.<br>
> <br>
> I think it is important to clarify that for both LXC and Xen testing should be able to happen in the upstream CI<br>
> system. Both are open source projects and the major gotcha to testing Xen in the past (reboots) should be possible<br>
> with Zuulv3. Typically we should fall back on third party CI when there are special hardware requirements or licenses<br>
> that prevent us from running software freely on our existing CI system. For open source tools like LXC and Xen I don't<br>
> believe this is a problem.<br>
yes that is all true. at present we have not had time to sit down and create a job for each.<br>
matt did have a poc job proposed for lxc which was partly working. i might consier creatign a job for each that runs as<br>
a periodic job and or on  a subset of nova patches but at present  i have some other ci jobs<br>
that i want to work on first. lxc/xen work for me is very much in the hobby work catagory but i<br>
did enjoy using nova with libvirt/lxc in the past and would like to see it work again in the future.<br>
it was quite nice for doing nested devstack without the overhead of two levels of vms. although when you<br>
get nested virt working its close from a performance point of view but still uses more memory then lxc.<br>
<br>
the lxc job itself in partalar is not much work to enabel the issue is that we cant actully pass tempest with lxc<br>
currently the cloud init fix will help but we also need to modify devstack to create a useable lxc image which is<br>
also relitivly trivial just need to be done.<br>
> <br>
> > <br>
> > -melanie<br>
> > <br>
> > > [1] <br>
> > > <a href="http://eavesdrop.openstack.org/meetings/nova/2019/nova.2019-10-17-14.00.log.html#l-287" rel="noreferrer" target="_blank">http://eavesdrop.openstack.org/meetings/nova/2019/nova.2019-10-17-14.00.log.html#l-287</a> <br>
> > > <br>
> > > [2] <a href="https://review.opendev.org/#/c/667976/" rel="noreferrer" target="_blank">https://review.opendev.org/#/c/667976/</a><br>
> > > [3] <a href="https://review.opendev.org/#/c/687827/" rel="noreferrer" target="_blank">https://review.opendev.org/#/c/687827/</a><br>
> > > [4] <br>
> > > <a href="https://github.com/openstack/nova/blob/1a226aaa9e8c969ddfdfe198c36f7966b1f692f3/nova/virt/libvirt/driver.py#L609" rel="noreferrer" target="_blank">https://github.com/openstack/nova/blob/1a226aaa9e8c969ddfdfe198c36f7966b1f692f3/nova/virt/libvirt/driver.py#L609</a> <br>
> <br>
> <br>
<br>
<br>
</blockquote></div>