settingsLogin | Registersettings

[openstack-dev] [nova][cinder] Pike PTG recap - nova/cinder

0 votes

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
volumetype 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.




Matt Riedemann

OpenStack Development Mailing List (not for usage questions)
asked Feb 28, 2017 in openstack-dev by mriedemos_at_gmail.c (15,720 points)   2 5 11