<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Aug 10, 2014 at 11:59 PM, Mark McLoughlin <span dir="ltr"><<a href="mailto:markmc@redhat.com" target="_blank">markmc@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>On Fri, 2014-08-08 at 09:06 -0400, Russell Bryant wrote:<br>
> On 08/07/2014 08:06 PM, Michael Still wrote:<br>
> > It seems to me that the tension here is that there are groups who<br>
> > would really like to use features in newer libvirts that we don't CI<br>
> > on in the gate. Is it naive to think that a possible solution here is<br>
> > to do the following:<br>
> ><br>
> > - revert the libvirt version_cap flag<br>
><br>
> I don't feel strongly either way on this. It seemed useful at the time<br>
> for being able to decouple upgrading libvirt and enabling features that<br>
> come with that.<br>
<br>
</div>Right, I suggested the flag as a more deliberate way of avoiding the<br>
issue that was previously seen in the gate with live snapshots. I still<br>
think it's a pretty elegant and useful little feature, and don't think<br>
we need to use it as proxy battle over testing requirements for new<br>
libvirt features.<br></blockquote><div><br></div><div>Mark,</div><div><br></div><div>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?</div>
<div><br></div><div>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.</div>
<div><br></div><div>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 '<span style="color:rgb(0,0,0);font-family:sans-serif">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 "</span><font color="#000000" face="sans-serif">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.</font></div>
<div><br></div><div><div>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'?</div>
</div><div><br></div><div>[0] <a href="https://review.openstack.org/#/c/102643/4/nova/virt/libvirt/driver.py" target="_blank">https://review.openstack.org/#/c/102643/4/nova/virt/libvirt/driver.py</a></div><div>[1] <a href="https://review.openstack.org/#/c/107119/" target="_blank">https://review.openstack.org/#/c/107119/</a></div>
<div>[2] <a href="https://review.openstack.org/#/c/110754/" target="_blank">https://review.openstack.org/#/c/110754/</a></div><div>[3] <a href="http://specs.openstack.org/openstack/nova-specs/specs/template.html#testing" target="_blank">http://specs.openstack.org/openstack/nova-specs/specs/template.html#testing</a></div>
<div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span><font color="#888888"><br>
Mark.<br>
</font></span><div><div><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>