Open Stack

On Sun, Aug 10, 2014 at 11:59 PM, Mark McLoughlin <markmc at redhat.com> wrote:

> On Fri, 2014-08-08 at 09:06 -0400, Russell Bryant wrote:
> > On 08/07/2014 08:06 PM, Michael Still wrote:
> > > It seems to me that the tension here is that there are groups who
> > > would really like to use features in newer libvirts that we don't CI
> > > on in the gate. Is it naive to think that a possible solution here is
> > > to do the following:
> > >
> > >  - revert the libvirt version_cap flag
> >
> > I don't feel strongly either way on this.  It seemed useful at the time
> > for being able to decouple upgrading libvirt and enabling features that
> > come with that.
>
> Right, I suggested the flag as a more deliberate way of avoiding the
> issue that was previously seen in the gate with live snapshots. I still
> think it's a pretty elegant and useful little feature, and don't think
> we need to use it as proxy battle over testing requirements for new
> libvirt features.
>

Mark,

I am not sure if I follow.  The gate issue with live snapshots has been
worked around by turning it off [0], so presumably this patch is forward
facing.  I fail to see how this patch is needed to help the gate in the
future. Wouldn't it just delay the issues until we change the version_cap?

The issue I see with the libvirt version_cap [1] is best captured in its
commit message: "The end user can override the limit if they wish to opt-in
to use of untested features via the 'version_cap' setting in the 'libvirt'
group." This goes against the very direction nova has been moving in for
some time now. We have been moving away from merging untested (re: no
integration testing) features.  This patch changes the very direction the
project is going in over testing without so much as a discussion. While I
think it may be time that we revisited this discussion, the discussion
needs to happen before any patches are merged.

I am less concerned about the contents of this patch, and more concerned
with how such a big de facto change in nova policy (we accept untested code
sometimes) without any discussion or consensus. In your comment on the
revert [2], you say the 'whether not-CI-tested features should be allowed
to be merged' debate is 'clearly unresolved.' How did you get to that
conclusion? This was never brought up in the mid-cycles as a unresolved
topic to be discussed. In our specs template we say "Is this untestable in
gate given current limitations (specific hardware / software configurations
available)? If so, are there mitigation plans (3rd party testing, gate
enhancements, etc)" [3].  We have been blocking untested features for some
time now.

I am further perplexed by what Daniel Berrange, the patch author, meant
when he commented [2] "Regardless of the outcome of the testing discussion
we believe this is a useful feature to have." Who is 'we'? Because I don't
see how that can be nova-core or even nova-specs-core, especially
considering how many members of those groups are +2 on the revert. So if
'we' is neither of those groups then who is 'we'?

[0] https://review.openstack.org/#/c/102643/4/nova/virt/libvirt/driver.py
[1] https://review.openstack.org/#/c/107119/
[2] https://review.openstack.org/#/c/110754/
[3]
http://specs.openstack.org/openstack/nova-specs/specs/template.html#testing




>
> Mark.
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140811/9f51b565/attachment.html>