Open Stack

On Thursday morning at the PTG the Cinder team invaded the Nova room to 
talk about cross-project items. The full etherpad is here [1].

Volume multi-attach
-------------------

This got it's own very special etherpad [2]. We went over some of the 
current status, like Cinder's 3.27 microversion (Ocata) adds the new 
volume attachment CRUD APIs.

The first thing we wanted to do, which needed a little bit of 
discussing, was landing Ildiko's patch which removes the check_attach 
calls in Nova [3]. That patch is now merged.

To use the new API flow, Nova needs to start using Cinder v3. Scott 
D'Angelo has a patch up for this [4]. We agreed that Nova will use 
Cinder v3 by default in Pike (it's been available since Newton and the 
initial microversion is backward compatible with Cinder v2). Outside of 
the session, Sean Dague suggested that Nova actually deprecate it's 
usage of Cinder v2 starting in Pike too, and make Cinder v3 required for 
Nova in Queens. That doesn't mean Cinder v2 is deprecated, it would mean 
Nova's usage of it would be and Nova, as a client, would start requiring 
Cinder v3 in Queens. The idea here is we can then drop old compat code 
in Nova in Queens for the pre-3.27 APIs.

Nova will determine which path to take for attach/detach of volumes 
based on:

1. Is Nova configured for Cinder v3?
2. Is Cinder 3.27 available?
3. Was the volume attachment created using the v2 API? If so, we have to 
fallback to detach the volume using the old detach APIs.

We talked a bit about data migrations and upgrades and ways that we 
could migrate old volume attachments to the new model in 3.27, but 
decided to defer that complexity from Pike.

We ironed out a few issues with error handling and evacuate which will 
be fed back into John Garbutt's Nova spec [5].

Finally, we outlined a rough set of steps to move the work forward:

- Update John's spec and get that merged.
- Merge Ildiko's patch to remove check_attach in Nova (done).
- Add support for cinder v3 in nova and default to cinder v3.
- Start doing the new 3.27 API flow. The plan here is to work backward 
from detach so the code doesn't all come in as one or two giant patches. 
We can plumb in detach first and nothing will be using it until later 
patches build on it, but it will make the review simpler. We then build 
in support for more operations like shelve/unshelve, live migration, 
evacuate, and finally attach. Once attach is supported using the new 
Cinder APIs, we can finish up with adding the multi-attach logic in the 
libvirt driver.

Enable Cinder as an ephemeral storage backend for Nova
------------------------------------------------------

This discussion came about from a POC that John Griffith had where you 
could define a block device mapping via flavor extra specs so that by 
default you're always doing boot from volume and the volume is always 
deleted when the instance is deleted. This would solve the use case of 
"I don't have local storage on my computes, I have Cinder and I want to 
use it for all of my storage needs."

There was a related spec previously approved in Nova that tried to solve 
the same problem, but in a different way. The Nova team does not want to 
go with the BDM in flavor extra-specs approach that John was proposing, 
but instead we talked about simply adding a new image backend in Nova 
that uses Cinder. This would allow us to replace the Rbd image backend 
for the libvirt driver, and should also resolve the need for a new 
ScaleIO image backend.

We also talked a bit about how long-term, you could provide the 
volume_type when creating a new volume using the Cinder image backend in 
Nova by putting the volume_type in the flavor extra specs; so that would 
solve another long-standing ask which Nova has pushed back on in the 
past for adding more proxy code into the REST API. However, encoding in 
flavor extra specs isn't necessarily fun either, so we're deferring the 
volume type discussion for now.

[1] https://etherpad.openstack.org/p/nova-ptg-pike-cinder
[2] https://etherpad.openstack.org/p/ptg-pike-cinder-nova-session
[3] https://review.openstack.org/#/c/335358/
[4] https://review.openstack.org/#/c/420201/
[5] https://review.openstack.org/#/c/373203/

-- 

Thanks,

Matt Riedemann