Open Stack

So would it help if those resources were able in CI 1st party? I would
really like to see the lxc driver move forward, but also am happy to work
at xen support too.

Obviously with CI resources its nice to have them available in all the
providers, but for these non-mainline drivers I think something could be
done to address it so we can continue to support them.



Donny Davis
c: 805 814 6800

On Fri, Oct 18, 2019, 6:25 AM Radosław Piliszek <radoslaw.piliszek at gmail.com>
wrote:

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