Hello everyone, thanks for a very productive PTG for the Dalmatian
cycle.  Below is a brief summary of the highlights.  The raw etherpad
notes are here[1] and both the summary and transcribed etherpad notes
are captured in our wiki here[2].

# Improve driver documentation

When proposing new or updating existing drivers, our interface can be
confusing.  We agreed on an effort to migrate class documentation to the
interface definitions, make clear the mandatory and optional methods for
drivers, and maintain this documentation going forward.

# User visible information in volume types

Volume type metadata and extra specs are not visible to users, making it
difficult to ascertain whether a volume type will lead to encryption or
replication.  Agreement was reached on metadata fields similar to
Glance's metadefs, allowing drivers to report capabilities in a standard
way and allowing that metadata to become visible to admins and users.

# Optional backup driver dependencies

Although volume driver dependencies are optional, those of our backup
drivers are listed in requirements and are therefore always installed
irrespective of deployment configuration.  Agreement was reached to move
these dependencies to driver-requirements.  This should simplify efforts
of both deployers and packagers.

# Simplify deployments

A few ideas were proposed to improve our deployment:

* When cinder-volume is deployed in an active-active configuration, our
  `backend_host` parameter must be updated on every backend to have the
  same value, we would like to remove this additional step. 
* Use of predictable names to define tenants, instead of unique IDs.
* Have dedicated quote section in our configuration for quote-related
  options.

# Response schema validation

A spec to add response schema validation in addition to our existing
request validation was proposed.  With adequate coverage, clients in
various languages could be autogenerated (in theory).  No significant
objects were raised, agreement to review related patches this cycle.

# Documentation of Ceph auth requirements

We do not provide comprehensive and easy-to-find documentation on
exactly what authentication/permission expectations there are between
different services, leading deployers troubleshoot themselves and not be
able to rely on upstream best practices.  Agreement to improve this
situation in the current cycle.

# Cinder backup improvements

An accumulation of bug fixes and performance improvements have stalled
in the review queue.  We went through the major ones as a team to
attempt to bring awareness and unblock the remaining review
requirements.  See WIKI notes for specific details.

# Migrating backups between multiple backends

There is desire to support multiple backup backends where new backups go
to a new backend while backups in an old backend remain readable.  We
want to avoid needing to create a full backup in the new backend to
support incremental snapshots (and the associated charge).  A spec will
be proposed for review and work towards this goal will proceed during
this cycle.

# Cross-project with Glance

In a cross-project collaboration with the Glance team, an improved
method for image migration was proposed.  Agreement to introduce a new
migration operation in Glance.  Cinder context was provided and a
consensus on path forward was reached.

# Cross-project with Nova

In a cross-project collaboration with both Nova and Glance, the topic of
image encryption was discussed.  Dan Smith from the Nova team provided
input from the Nova side.  Cinder and Nova expect LUKS formatted images,
but Glance currently supports GPG encrypted images - requiring
re-encryption prior to use.  It was noted that LUKS encrypted images can
be created without root permission and the Glance team is now looking to
drop GPG support and consolidate around LUKS as our unified format.

# Active-Active support for NetApp

A NetApp engineer raised questions about adding active-active support to
the driver.  Questions were answered and that work should proceed in
this cycle.

# Performance of parallel clone operations

For the clone operation in cinder we're using a single distributed lock
to prevent the source volume from being deleted mid-operation.  This
causes multiple concurrent clone operations to block.  Under the right
conditions, this can cause a significant performance degradation.
Multiple possible solutions were discussed (read-write locks) and a
consensus to use the DB was reached.  Some details are unclear, awaiting
a spec before moving forward.

# Volume encryption with user defined keys

Cinder does not currently support encryption with key provided by the
user.  Users could both manage their own keys and data could be
recovered even if keys are lost at the deployment.  There are several
technical challenges to support this.  Several of these hurdles were
raised, more thought and research is needed before we have a spec that
could be reviewed.

[1] https://etherpad.opendev.org/p/dalmatian-ptg-cinder
[2] https://wiki.openstack.org/wiki/CinderDalmatianPTGSummary

--
Jon