On Thursday morning at the PTG the Nova and Cinder teams got together to
talk through some items. Details are in the etherpad [1].
Bug 1547142 [2]
---------------
This is a long-standing bug where Nova does not terminate connections
when shelve offloading an instance. There was some confusion when this
was originally reported about whether or not calling
os-terminate_connection would fix the issue for all backends. The Cinder
team said it should, and if not it's a bug in the volume drivers in
Cinder. So we went ahead and rebased the fix [3] which is merged and
making its way through the stable backports now. This fixes old-style
attachments. For the new style attachments which get enabled in [4]
we'll also have to make sure that we create a new volume attachment to
keep the volume reserved but delete the old attachments for the old host
connector.
New style volume attach dev update
----------------------------------
The Cinder team gave an overview of the work completed in Pike and what
is on-going in Queens for enabling Nova to use new-style volume
attachments in Cinder, which are based on the 3.27 and 3.44 Cinder API
microversions. This was also a chance to merge some patches in the
Queens series and give background to the review teams, mostly on the
Nova side.
There was general agreement to get the new-style attachment flows merged
early in Queens so we can flush out bugs and start working on
multi-attach support.
We also said that we would not work on migrating old style attachments
to new style in Queens. We don't plan on removing the old flows in Nova
anytime soon, and once we do we can start talking about migrating data then.
Volume multi-attach
-------------------
Most of the discussion here was around shared volume connections and how
to model those out of the Cinder API so that Nova can know when it
should perform a final disconnect_volume call on the host when detaching
a volume. We agreed that Cinder needs a new API microversion to model
this which we will then update [4] to rely on that new microversion
before enabling new style attachments.
We also talked about whether or not we should allow boot from volume
with an existing multi-attach volume. We decided to allow this but
disable it via default policy. So there will be a new policy rule in
both Nova and Cinder:
1. Nova: add a policy rule, disabled by default, to allow boot from
volume with a multi-attach volume.
2. Cinder: allow multi-attach volumes based on the storage backend
support, allow multi-attach but only for read-only volumes, or disable
creating multi-attach volumes altogether. I'm a bit fuzzy on the details
here, but looking at the existing Cinder API code I don't see any policy
checks for creating a multiattach volume at all, so this is probably
something good to add anyway since not all Nova compute drivers are
going to support multiattach volumes right away.
Ildiko Vancsa is updating the nova spec for multi-attach support for
Queens with the new details.
Refreshing volume connection_info
---------------------------------
This was based on a mailing list discussion [5] and the PTG discussion
was already summarized in that thread [6].
Cinder ephemeral storage
------------------------
This was a rehash of the Boston forum discussion [7]. We agreed to work
on both the short term and long term options here.
The short-term option is adding an "is_bfv" attribute on flavors in
Nova, which defaults to False, but if True would perform a simple boot
from volume using the specified image and flavor disk details. Think of
this like get-me-a-network but for boot from volume. Anything more
detailed, like volume type, guest_format, disk_bus, ephemeral or swap
disks, would have to be handled through the normal API usage we have
today. Also, user-defined or image-defined block device mapping
attributes in the request would supersede the flavor.
The long-term option option is Nova having a Cinder imagebackend driver
for ephemeral storage. Chet Burgess has started looking at this, and it
was recommended to look at the ScaleIO imagebackend as a template since
they both have to solve problems with non-local storage. The good news
is a Cinder ephemeral imagebackend driver in Nova would not need to deal
with image caching, since Cinder can do that for us.
--
All in all I felt we had a really productive set of topics and
discussions between the teams with everyone being on the same page and
going the same direction, which is nice to see. Boring is good.
[1] https://etherpad.openstack.org/p/cinder-ptg-queens
[2] https://bugs.launchpad.net/nova/+bug/1547142
[3] https://review.openstack.org/257275
[4] https://review.openstack.org/#/c/330285/
[5] http://lists.openstack.org/pipermail/openstack-dev/2017-June/118040.html
[6]
http://lists.openstack.org/pipermail/openstack-dev/2017-September/122170.html
[7] http://lists.openstack.org/pipermail/openstack-dev/2017-May/117012.html
--
Thanks,
Matt
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
