[nova][cinder] Why can't nova in stein work with cinder from queens?

Jay S Bryant jungleboyj at gmail.com
Wed Nov 28 17:40:18 UTC 2018


Matt,

We discussed this in our team meeting today and it appears that the 
source of the problem is a misunderstanding based on Sean's commit message.

Sean had made that comment because we only test N with N-1.  So, that is 
the only tested configuration.  There is no reason that we know of, 
however, that using Nova with older versions of Cinder wouldn't work.  
Assuming that versioning works the way that it is supposed to, then 
other combinations should work.  We, however, don't recommend using 
combinations other than Nova at N and Cinder at N-1 as that is what is 
tested.

Let me know if you have further questions.

Thanks!

Jay



On 11/21/2018 3:11 PM, Matt Riedemann wrote:
> A change in nova [1] was approved which makes an assertion that we 
> (nova? openstack?) do not support running nova from stein with cinder 
> from queens, and I guess I'd like to know where that support statement 
> is written down? Granted, I know we don't gate that way but I'm not 
> aware of anything preventing it from working given we use 
> microversions and nova, as the client, should be able to work with 
> cinder from v1, v2 or v3 assuming it's doing version discovery 
> correctly (which we've been doing in nova since queens when we needed 
> to start using the cinder v3.44 volume attachments API for multiattach 
> - but it's not required).
>
> In fact, nova-api still has compatibility code for older versions of 
> cinder to determine what it should do about working with volume 
> attachments [2]. I've been thinking lately about how to drop that code 
> which would at the very least require a release note saying nova 
> requires cinder >= queens, but nothing like that was requested in the 
> change that drops support for cinder v1 from nova and asserts that 
> nova in stein requires cinder >= queens.
>
> Maybe I'm just yelling at kids to get off my lawn, but I don't really 
> want this to be precedent without some discussion because I know at 
> various times operators have complained about upgrades being hard 
> because they assume all of the services must be upgraded to the same 
> release at the same time, and I don't think that is true, or should be 
> true, because if it is, we're doing a really bad job of defining 
> versioned interfaces between the services.
>
> [1] https://review.openstack.org/#/c/617927/
> [2] 
> https://github.com/openstack/nova/blob/7217e38bafb75e8a613763835b64e48e6b2c8ece/nova/compute/api.py#L4260-L4264
>




More information about the openstack-discuss mailing list