Open Stack

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