Re: [openstack-dev] [nova][cinder] Should nova just default to use cinder v3 in Pike?

[John Griffith]

On Sat, Feb 11, 2017 at 11:29 AM, Matt Riedemann 
wrote:

> On 2/11/2017 11:47 AM, John Griffith wrote:
>
>>
>> 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.
>>
>>
>>
> Scott's nova patch to support cinder v3 is dependent on a
> python-cinderclient change for version discovery for min/max versions in
> the v3 API. Once that's released we just bump the minimum required
> cinderclient in global-requirements for pike and we should be good to go
> there.
>
> But overall yeah I like the idea of just defaulting to cinderv3 in Pike,
> as long as we can still get cinderv2 coverage in CI in master, which I
> think we can do via grenade jobs.


​+1
​

>
>
> --
>
> Thanks,
>
> Matt Riedemann
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][cinder] Should nova just default to use cinder v3 in Pike?

[Matt Riedemann]

On 2/11/2017 11:47 AM, John Griffith wrote:


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.




Scott's nova patch to support cinder v3 is dependent on a 
python-cinderclient change for version discovery for min/max versions in 
the v3 API. Once that's released we just bump the minimum required 
cinderclient in global-requirements for pike and we should be good to go 
there.


But overall yeah I like the idea of just defaulting to cinderv3 in Pike, 
as long as we can still get cinderv2 coverage in CI in master, which I 
think we can do via grenade jobs.


--

Thanks,

Matt Riedemann

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][cinder] Should nova just default to use cinder v3 in Pike?

[John Griffith]

On Fri, Feb 10, 2017 at 1:33 PM, Matt Riedemann  wrote:

> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> [1] https://review.openstack.org/#/c/420201/
> [2] https://review.openstack.org/#/c/431704/
>
> --
>
> Thanks,
>
> Matt Riedemann
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev