Open Stack

Matt,

As far as I know this is news to the Cinder team.  Will bring it up in 
our weekly meeting to see if anyone was aware of this stance.

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
>