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/7217e38bafb75e8a613763835b64e48e6b2c8...