Open Stack

For those who couldn't attend, here's a quick synopsis of what was
discussed yesterday.

Please consult the etherpad for each session for details.  Feel free
to put questions/comments on the etherpads, and then put an item on
the agenda for the weekly meeting on Thursday 21 September, and we'll
continue the discussion.


Complexity removal
------------------
https://etherpad.openstack.org/p/glance-queens-ptg-complexity-removal

In terms of a complexity contribution barrier, everyone agreed that
the domain model is the largest factor.

We also agreed that simplifying it is not something that could happen
in the Queens cycle.  It's probably a two-cycle effort, one cycle to
ensure sufficient test coverage, and one cycle to refactor.  Given the
strategic planning session yesterday, we probably wouldn't want to
tackle this until after the registry is completely removed, which is
projected to happen in S.


Image lifecycle support
-----------------------
https://etherpad.openstack.org/p/glance-queens-ptg-lifecycle

We sketched out several approaches, but trying to figure out a
solution that would work across different types of deployments and
various use cases gets complicated fast.  It would be better for
deployers to use Searchlight to configure complex queries that could
use all appropriate image metadata specified by the deployer.

For interoperability, deployers could use the common image properties
with suggested values on their public images.

We looked at two particular approaches that might help operators.  The
first would be introducing a kind of 'local_version' field that would
be auto-incremented by Glance, the idea being that an image-list query
that asked for the max value would yield the most recent version of
that image.  One problem, however, is what other metadata would be
used in the query, as there might be several versions of images with
the same os_distro and os_version properties (for example, the base
CentOS 7 image and the LAMP CentOS 7 image).

The second approach is introducing a 'hidden' property which would
cause the image to be hidden from any image list calls (except for the
image owner or glance admin).  This has been requested before, but
hasn't been enthusiastically endorsed because it leaves out several
use cases.  But combined with Searchlight (with an updated glance
plugin to understand the 'hidden' field), it might be the best
solution.


Should Glance be replaced?
--------------------------
https://etherpad.openstack.org/p/glance-queens-ptg-glance-removal

The short answer is No.  Glance is the best way for deployments to
provide the Images API v2.  The project team has recently regained the
team:diverse-affiliation tag and is in a healthier state that it was
immediately after the downsizing craze of 2017 that happened early in
the Pike cycle.  The Glance project team is committed to the long term
stability of Glance.


glance_store
------------
https://etherpad.openstack.org/p/glance-queens-ptg-glance_store

We had a combined session with the Glare team, who also consume the
glance_store library, and worked out a list of items to improve the
library.



Multiple same store type support
--------------------------------
https://etherpad.openstack.org/p/glance-queens-ptg-multi-store

This has been requested by operators, and the interoperable image
import introduced in v2.6 of the Images API can be used to allow end
users to request what store to use.  The Glance design will be
consistent (to the largest extent possible) with Cinder (at least as
far as configuration goes, to make it easy on operators).



Queens Prioritization and Roadmapping
-------------------------------------
https://etherpad.openstack.org/p/glance-queens-ptg-roadmap

See the etherpad for what we think we can get done.  I'll put up a
patch for the Queens priorities to the glance-specs repo before the
Glance meeting on Sept 21, and we can have a final discussion of any
outstanding issues.



If you missed the Wednesday summary, here it is:
http://lists.openstack.org/pipermail/openstack-dev/2017-September/122156.html

The scheduling etherpad has links to all the session etherpads:
https://etherpad.openstack.org/p/glance-queens-ptg