<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 10, 2017 at 1:33 PM, Matt Riedemann <span dir="ltr"><<a href="mailto:mriedemos@gmail.com" target="_blank">mriedemos@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">While talking about [1] yesterday and trying to figure out how to configure nova to use cinder v3 in the CI jobs in Pike, things got a bit messy from the CI job configuration perspective.<br>
<br>
My initial plan was to make the nova-next (formerly "placement" job [2]) use cinder v3 but that breaks down a bit when that job runs on stable/newton where nova doesn't support cinder v3.<br>
<br>
So when the cat woke me up at 3am I couldn't stop thinking that we should just default "[cinder]/catalog_info" in nova.conf to cinderv3 in Pike. Then CI on master will be running nova + cinder v3 (which should be backward compatible with cinder v2). That way I don't have to mess with marking a single CI job in master as using cinder v3 when by default they all will.<br>
<br>
We'll still want some nova + cinder v2 coverage and I initially though grenade would provide that, but I don't think it will since we don't explicitly write out the 'catalog_info' value in nova.conf during a devstack run, but we could do that in stable/ocata devstack and then it would persist through an upgrade from Ocata to Pike. There are other ways to get that coverage too, that's just my first thought.<br>
<br>
Anyway, I just remembered this and it was middle-of-the-night thinking, so I'm looking to see if this makes sense or what is wrong with it.<br>
<br>
[1] <a href="https://review.openstack.org/#/c/420201/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/420201/</a><br>
[2] <a href="https://review.openstack.org/#/c/431704/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/431704/</a><span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt Riedemann<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</font></span></blockquote></div><br></div><div class="gmail_extra"><div class="gmail_default" style="font-family:monospace,monospace">It seems like just moving Nova to V3 in Pike would alleviate quite a few snarls here.  The fact that V3.0 is just pointing back to V2 for Cinder calls anyway I'm uncertain there's a huge downside to this.  Nova + Cinder V2 coverage is only an entry point issue IIUC (V3.0 points to Cinder V2 API server calls anyway based on what I was looking at).  So it's more an issue of cinderclient and what it's set up at no?  Honestly, this is another one of those things we probably need to unwind together at PTG.  The V3 Cinder thing has proven to be quite thorny.</div><br></div></div>