Open Stack

On Thu, 2019-10-17 at 09:33 -0700, 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 cant speak for the xen change but at least in the case of the lxc change
i was able to test it myself and comment as such on the patch.
the author also explained how they were testing and i was able to follow there
steps to reproduce it. so while i dont think we shoudl have to deploy each change
ourselves if it does not have automated ci if it trival and someone volunteers to test it
then i think that is another reason to allow such changes.

i think the openstack mantra of if its not in ci its probably broke still applies but
we have that quality warning in the logs on start up which was mentioned so operator
know what are getting into upfront.

> 
> -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 
> > 
> > 
> 
>