<div dir="ltr">Thanks Sean for the nice recap, helps folks who couldn't attend the summit.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 5, 2015 at 2:53 AM, Sean McGinnis <span dir="ltr"><<a href="mailto:sean.mcginnis@gmx.com" target="_blank">sean.mcginnis@gmx.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Cinder Mitaka Design Summit Summary<br>
<br>
Will the Real Block Storage Service Please Stand Up<br>
===================================================<br>
Should Cinder be usable outside of a full OpenStack environment.<br>
There are several solutions out there for providing a Software<br>
Defined Storage service with plugins for various backends. Most<br>
of the functionality used for these is already done by Cinder.<br>
So the question is, should Cinder try to be that ubiquitous SDS<br>
interface?<br>
<br>
The concern is that Cinder should either try to address this<br>
broader use case or be left behind. Especially since there is<br>
already a lot of overlap in functionality, and end users already<br>
asking about it.<br>
<br>
Some concern about doing this is whether it will be a distraction<br>
from our core purpose - to be a solid and useful service for<br>
providing block storage in an OpenStack cloud.<br>
<br>
On the other hand, some folks have played around with doing this<br>
already and found there really are only a few key issues with<br>
being able to use Cinder without something like Keystone. Based on<br>
this, it was decided we will spend some time looking into doing<br>
this, but at a lower priority than our core work.<br>
<br>
Availability Zones in Cinder<br>
============================<br>
Recently it was highlighted that there are issues between AZs<br>
used in Cinder versus AZs used in Nova. When Cinder was originally<br>
branched out of the Nova code base we picked up the concept of<br>
Availability Zones, but the ideas was never fully implemented and<br>
isn't exactly what some expect it to be in its current state.<br>
<br>
Speaking with some of the operators in the room, there were two<br>
main desires for AZ interaction with Nova - either the AZ specified<br>
in Nova needs to match one to one with the AZ in Cinder, or there<br>
is no connection between the two and the Nova AZ doesn't matter on<br>
the Cinder side.<br>
<br>
There is currently a workaround in Cinder. If the config file<br>
value for allow_availability_zone_fallback is set to True, if a<br>
request for a new volume comes in with a Nova AZ not present, the<br>
default Cinder AZ will be used instead.<br>
<br>
A few options for improving AZ support were suggested. At least for<br>
those present, the current "dirty fix" workaround is sufficient. If<br>
further input makes it clear that this is not enough, we can look<br>
in to one of the proposed alternatives to address those needs.<br>
<br>
API Microversions<br>
=================<br>
Some projects, particularly Nova and Manila, have already started<br>
work on supporting API microversions. We plan on leveraging their<br>
work to add support in Cinder. Scott D'Angelo has done some work<br>
porting that framework from Manila into a spec and proof of concept<br>
in Cinder.<br>
<br>
API microversions would allow us to make breaking API changes while<br>
still providing backward compatibility to clients that expect the<br>
existing behavior. It may also allow us to remove functionality<br>
more easily.<br>
<br>
We still want to be restrictive about modifying the API. Just<br>
because this will make it slightly easier to do, it still has<br>
an ongoing maintenance cost, and slightly a higher one at that,<br>
that we will want to limit as much as possible.<br>
<br>
A great explanation of the microversions concept was written up by<br>
Sean Dague here:<br>
<br>
<a href="https://dague.net/2015/06/05/the-nova-api-in-kilo-and-beyond-2/" rel="noreferrer" target="_blank">https://dague.net/2015/06/05/the-nova-api-in-kilo-and-beyond-2/</a><br>
<br>
Experimental APIs<br>
=================<br>
Building on the work with microversions, we would use that to expose<br>
experimental APIs and make it explicit that they are experimental<br>
only and could be removed at any time, without the normal window<br>
provided with deprecating other features.<br>
<br>
Although there were certainly some very valid concerns raised about<br>
doing this, and whether it would be useful or not, general consensus<br>
was that it would be good to support it.<br>
<br>
After further discussion, it was pointed out that there really isn't<br>
anything in the works that needs this right now, so it may be delayed.<br>
The issue there being that if we wait to do it, when we actually do<br>
need to use it for something it won't be ready to go.<br>
<br>
Cinder Nova Interaction<br>
=======================<br>
Great joint session with some of the Nova folks. Talked through some<br>
of the issues we've had with the interaction between Nova and Cinder<br>
and areas where we need to improve it.<br>
<br>
Some of the decisions were:<br>
- Working on support for multiattach. Will delay encryption support<br>
  until non-encrypted issues get worked out.<br>
- Rootwrap issues with the use of os-brick. Priv-sep sounds like it<br>
  is the better answer. Will need to wait for that to mature before<br>
  we can switch away from rootwrap though.<br>
- API handling changes. A lot of cases where an API call is made and<br>
  it is assumed to succeed. Will use event notifications to report<br>
  results back to Nova. Requires changes on both sides.<br>
- Specs will be submitted for coordinated handling for extending<br>
  volumes.<br>
- Volume related Nova bugs were highlighted. Cinder team will try to<br>
  help triage and resolve some of those.<br>
  <a href="https://bugs.launchpad.net/nova/+bugs?field.tag=volumes" rel="noreferrer" target="_blank">https://bugs.launchpad.net/nova/+bugs?field.tag=volumes</a><br>
<br>
Volume Manager Locks<br>
====================<br>
Covered in cross-project discussion on DLM. Will use tooz as an<br>
abstraction layer. Default will use local locks, so no change for<br>
those that don't need it, but ability to plug in DLMs like<br>
zookeeper, etc., for those that need the DLM functionlity.<br>
<br>
C-Vol Active/Active HA<br>
======================<br>
Discussed the desire to be able to run the c-vol service in an a/a<br>
configuration. It can kind of be done now with things like pacemaker,<br>
but there are definite issues and is considered risky. The desire<br>
is to build in support to Cinder to be able to run A/A, but we don't<br>
want to impose heavy requirements on operators running smaller<br>
deployments or deployments that do not require A/A.<br>
<br>
Based on the DLM discussion, we should be able to support this based<br>
on end user configuration. If appropriate locking is in place within<br>
the Cinder code and using the tooz locking abstraction, on single<br>
node installations it will just work without extra overhead. If A/A<br>
is desired, configuring tooz to use a distributed locking mechanism<br>
will provide locking across nodes without changes to the code.<br>
<br>
ABC Work<br>
========<br>
General agreement that our inheritance model is currently a mess<br>
and needs to be cleaned up. Need to work through it. Either collapse<br>
all into a common, simpler, driver base or make our inhertance model<br>
usable. Report capbilities rather than discover via inheritance?<br>
<br>
Cinder Driver Interface<br>
=======================<br>
This is a common area of confusion for new driver developers and we<br>
have even found that folks involved with the project for some time<br>
weren't always clear on what was expected for each call. This is an<br>
attempt to capture those details more clearly without needing to<br>
trace through all of the code to understand the basics.<br>
<br>
Eric has started documenting our driver requirements and is making<br>
great progress. This should also help to have a better reference as<br>
we work through the ABC and inheritance cleanup.<br>
<br>
Driver Deadlines<br>
================<br>
General consensus that past restrictions were a good attempt to bring<br>
some order and focus to work during the cycle, but there were too<br>
many different deadlines to keep track of and it didn't really solve<br>
all our problems as well as we had hoped.<br>
<br>
Based on the discussion, deadlines for the Mitaka cycle have been<br>
adjusted. See the mailing list post for full details:<br>
<br>
<a href="http://lists.openstack.org/pipermail/openstack-dev/2015-November/078215.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2015-November/078215.html</a><br>
<br>
Working Session Sprints<br>
=======================<br>
We spent the day Friday working through a long list of various topics to<br>
discuss. Some of the highlights from the discussion are:<br>
<br>
- Consistency group replication. We are looking in to what this would look<br>
  like now, though there was a lot of concern about adding on top of basic<br>
  replication before we at least have a few drivers implementing it. This<br>
  spec should be used for awareness for the current drivers looking at<br>
  replication support to make sure they are ready for the next step.<br>
- We have consistency groups, but some arrays support concepts such as<br>
  replication groups or even arbitrary grouping of volumes. No changes<br>
  planned at this point, but some ideas being floated around for having a<br>
  more generic volume grouping to support other scenarios.<br>
- Snapshot backup. We support backing up volumes, but we don't support<br>
  backing up snapshots currently. A spec is in the works to make this a<br>
  supported option.<br>
- Config file setting inheritance. To make it clear what settings are<br>
  inherited by later sections and what are not, considering adding a new<br>
  section to clearly break out what should apply to everything and what<br>
  should be specific to each section.<br>
- We discussed if there was any functionality to pull in to the set of<br>
  minimum required features. Nothing was selected at this time. We may<br>
  add some after all current drivers have more functionality that can<br>
  be considered de facto minimum features.<br>
- We need functional tests. Some work has started, but help is needed to<br>
  expand this. Could be a big win for ensuring better test coverage.<br>
- Ongoing work for conversion to objects and RPC versioning. It was<br>
  agreed this is something we want and it should be completed. This will<br>
  allow rolling upgrades. We plan to support only N-1 upgrades.<br>
- Call out for attention to the LVM driver. Anyone who would like to<br>
  help maintain it - help would be welcome.<br>
<br>
<br>
Priorities for Mitaka<br>
=====================<br>
- Active/Active High Availability<br>
- Rolling upgrade support<br>
- API Microversions<br>
- Functional testing<br>
- Completion of replication<br>
<br>
For the first time, all Design Summit sessions were live streamed and<br>
recorded for later playback. All sessions are available on the<br>
openstack-cinder YouTube channel:<br>
<br>
<a href="https://www.youtube.com/channel/UCJ8Koy4gsISMy0qW3CWZmaQ" rel="noreferrer" target="_blank">https://www.youtube.com/channel/UCJ8Koy4gsISMy0qW3CWZmaQ</a><br>
<br>
A big thank you to Walter Boring for making this possible.<br>
<br>
And a big thanks to all contributors in making this a successful design summit!<br>
<br>
Sean (smcginnis)<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div>