Re: [openstack-dev] [Cinder] Mitaka Design Summit Recap

[Deepak Shetty]

Thanks Sean for the nice recap, helps folks who couldn't attend the summit.

On Thu, Nov 5, 2015 at 2:53 AM, Sean McGinnis  wrote:

> Cinder Mitaka Design Summit Summary
>
> Will the Real Block Storage Service Please Stand Up
> ===
> Should Cinder be usable outside of a full OpenStack environment.
> There are several solutions out there for providing a Software
> Defined Storage service with plugins for various backends. Most
> of the functionality used for these is already done by Cinder.
> So the question is, should Cinder try to be that ubiquitous SDS
> interface?
>
> The concern is that Cinder should either try to address this
> broader use case or be left behind. Especially since there is
> already a lot of overlap in functionality, and end users already
> asking about it.
>
> Some concern about doing this is whether it will be a distraction
> from our core purpose - to be a solid and useful service for
> providing block storage in an OpenStack cloud.
>
> On the other hand, some folks have played around with doing this
> already and found there really are only a few key issues with
> being able to use Cinder without something like Keystone. Based on
> this, it was decided we will spend some time looking into doing
> this, but at a lower priority than our core work.
>
> Availability Zones in Cinder
> 
> Recently it was highlighted that there are issues between AZs
> used in Cinder versus AZs used in Nova. When Cinder was originally
> branched out of the Nova code base we picked up the concept of
> Availability Zones, but the ideas was never fully implemented and
> isn't exactly what some expect it to be in its current state.
>
> Speaking with some of the operators in the room, there were two
> main desires for AZ interaction with Nova - either the AZ specified
> in Nova needs to match one to one with the AZ in Cinder, or there
> is no connection between the two and the Nova AZ doesn't matter on
> the Cinder side.
>
> There is currently a workaround in Cinder. If the config file
> value for allow_availability_zone_fallback is set to True, if a
> request for a new volume comes in with a Nova AZ not present, the
> default Cinder AZ will be used instead.
>
> A few options for improving AZ support were suggested. At least for
> those present, the current "dirty fix" workaround is sufficient. If
> further input makes it clear that this is not enough, we can look
> in to one of the proposed alternatives to address those needs.
>
> API Microversions
> =
> Some projects, particularly Nova and Manila, have already started
> work on supporting API microversions. We plan on leveraging their
> work to add support in Cinder. Scott D'Angelo has done some work
> porting that framework from Manila into a spec and proof of concept
> in Cinder.
>
> API microversions would allow us to make breaking API changes while
> still providing backward compatibility to clients that expect the
> existing behavior. It may also allow us to remove functionality
> more easily.
>
> We still want to be restrictive about modifying the API. Just
> because this will make it slightly easier to do, it still has
> an ongoing maintenance cost, and slightly a higher one at that,
> that we will want to limit as much as possible.
>
> A great explanation of the microversions concept was written up by
> Sean Dague here:
>
> https://dague.net/2015/06/05/the-nova-api-in-kilo-and-beyond-2/
>
> Experimental APIs
> =
> Building on the work with microversions, we would use that to expose
> experimental APIs and make it explicit that they are experimental
> only and could be removed at any time, without the normal window
> provided with deprecating other features.
>
> Although there were certainly some very valid concerns raised about
> doing this, and whether it would be useful or not, general consensus
> was that it would be good to support it.
>
> After further discussion, it was pointed out that there really isn't
> anything in the works that needs this right now, so it may be delayed.
> The issue there being that if we wait to do it, when we actually do
> need to use it for something it won't be ready to go.
>
> Cinder Nova Interaction
> ===
> Great joint session with some of the Nova folks. Talked through some
> of the issues we've had with the interaction between Nova and Cinder
> and areas where we need to improve it.
>
> Some of the decisions were:
> - Working on support for multiattach. Will delay encryption support
>   until non-encrypted issues get worked out.
> - Rootwrap issues with the use of os-brick. Priv-sep sounds like it
>   is the better answer. Will need to wait for that to mature before
>   we can switch away from rootwrap though.
> - API handling changes. A lot of cases where an API call is made and
>   it is assumed to succeed. Will use event notifications to report
>   results back 

[openstack-dev] [Cinder] Mitaka Design Summit Recap

[Sean McGinnis]

Cinder Mitaka Design Summit Summary

Will the Real Block Storage Service Please Stand Up
===
Should Cinder be usable outside of a full OpenStack environment.
There are several solutions out there for providing a Software
Defined Storage service with plugins for various backends. Most
of the functionality used for these is already done by Cinder.
So the question is, should Cinder try to be that ubiquitous SDS
interface?

The concern is that Cinder should either try to address this
broader use case or be left behind. Especially since there is
already a lot of overlap in functionality, and end users already
asking about it.

Some concern about doing this is whether it will be a distraction
from our core purpose - to be a solid and useful service for
providing block storage in an OpenStack cloud.

On the other hand, some folks have played around with doing this
already and found there really are only a few key issues with
being able to use Cinder without something like Keystone. Based on
this, it was decided we will spend some time looking into doing
this, but at a lower priority than our core work.

Availability Zones in Cinder

Recently it was highlighted that there are issues between AZs
used in Cinder versus AZs used in Nova. When Cinder was originally
branched out of the Nova code base we picked up the concept of
Availability Zones, but the ideas was never fully implemented and
isn't exactly what some expect it to be in its current state.

Speaking with some of the operators in the room, there were two
main desires for AZ interaction with Nova - either the AZ specified
in Nova needs to match one to one with the AZ in Cinder, or there
is no connection between the two and the Nova AZ doesn't matter on
the Cinder side.

There is currently a workaround in Cinder. If the config file
value for allow_availability_zone_fallback is set to True, if a
request for a new volume comes in with a Nova AZ not present, the
default Cinder AZ will be used instead.

A few options for improving AZ support were suggested. At least for
those present, the current "dirty fix" workaround is sufficient. If
further input makes it clear that this is not enough, we can look
in to one of the proposed alternatives to address those needs.

API Microversions
=
Some projects, particularly Nova and Manila, have already started
work on supporting API microversions. We plan on leveraging their
work to add support in Cinder. Scott D'Angelo has done some work
porting that framework from Manila into a spec and proof of concept
in Cinder.

API microversions would allow us to make breaking API changes while
still providing backward compatibility to clients that expect the
existing behavior. It may also allow us to remove functionality
more easily.

We still want to be restrictive about modifying the API. Just
because this will make it slightly easier to do, it still has
an ongoing maintenance cost, and slightly a higher one at that,
that we will want to limit as much as possible.

A great explanation of the microversions concept was written up by
Sean Dague here:

https://dague.net/2015/06/05/the-nova-api-in-kilo-and-beyond-2/

Experimental APIs
=
Building on the work with microversions, we would use that to expose
experimental APIs and make it explicit that they are experimental
only and could be removed at any time, without the normal window
provided with deprecating other features.

Although there were certainly some very valid concerns raised about
doing this, and whether it would be useful or not, general consensus
was that it would be good to support it.

After further discussion, it was pointed out that there really isn't
anything in the works that needs this right now, so it may be delayed.
The issue there being that if we wait to do it, when we actually do
need to use it for something it won't be ready to go.

Cinder Nova Interaction
===
Great joint session with some of the Nova folks. Talked through some
of the issues we've had with the interaction between Nova and Cinder
and areas where we need to improve it.

Some of the decisions were:
- Working on support for multiattach. Will delay encryption support
  until non-encrypted issues get worked out.
- Rootwrap issues with the use of os-brick. Priv-sep sounds like it
  is the better answer. Will need to wait for that to mature before
  we can switch away from rootwrap though.
- API handling changes. A lot of cases where an API call is made and
  it is assumed to succeed. Will use event notifications to report
  results back to Nova. Requires changes on both sides.
- Specs will be submitted for coordinated handling for extending
  volumes.
- Volume related Nova bugs were highlighted. Cinder team will try to
  help triage and resolve some of those.
  https://bugs.launchpad.net/nova/+bugs?field.tag=volumes

Volume Manager Locks

Covered in