Open Stack

The Glance PTG schedule etherpad contains links to the etherpads for
each of the sessions discussed below:
https://etherpad.openstack.org/p/glance-pike-ptg-schedule

1. Short topics
dharinic led a discussion of a three recent items she's been looking
into.  First up was how the Glance limited JSON patch support could be
enhanced to allow JSON pointer references to particular tags.  Consensus
was that Glance supports the json-patch standard correctly for tags.
Although we don't completely implement json-pointer (as is clearly
documented), it doesn't make sense to do so in this case because
tags are a set (hence unordered), so you can't meaningfully index into
them.  They look like a list, but that's because of the representational
limitations of JSON.  Also, there's already a "tags" API in v2 that
allows a user to refer to individual tags by name.  Thus, we'll leave
the tags support as is.
  Next up was a discussion of how the v2 API is handling range requests
for partial downloads in v2.  Consensus was to fix this as dharinic
proposed.
  Final topic was supporting more complicated JSON schemas than Glance
currently uses.  dharinic has some ideas of how to do this and will put
up a patch where it can be discussed.

2. What's up with Glance docs?
asettle (docs PTL) met with the team to discuss what docs the Glance
team should be maintaining and what manuals are handled by the docs
team.  It became clear that the Glance docs need an information
architecture rennovation to make the content more accessible to the
various intended audiences (developers, operators, admins, end-users).
Once we get them organized better, it will be easier to reduce
redundancy and add enhancements.  Several glancers volunteered to be
contacts for asettle as she proposes a basic reorg.

3. Pike Community Goals
alex_bash reported on the two Pike goals and what the likely impact on
Glance will be.  alex_bash has been putting up patches over the past few
weeks to fix the Glance functional tests that were failing under Python
3.5, so that work is actually close to completion.  (Kudos to
alex_bash!)  The wsgi goal for Pike is limited enough (run the current
Images API in mod_wsgi in devstack) that alex_bash is optimistic that it
can be completed without too many complications.  Additionally,
alex_bash volunteered to implement the wsgi community goal, so Glance
looks to be in good shape for these.
  Patches are up for the Glance planning artifacts:
- https://review.openstack.org/#/c/437349/
- https://review.openstack.org/#/c/437354/

4. Image import refactor (session 1)
We discussed jokke's proposal for the import backend (the "stage") and
considered one or two alternatives, but ultimately decided that jokke is
on the right track for an MVP implementation in Pike.

5. The Future of glance
See the etherpad for a few things that were suggested.  The team was
pretty exhausted by the previous session, so we kept this one short.
Plus, there's the glance/glare session Thursday morning where this will
be discussed a bit more.
- https://etherpad.openstack.org/p/glance-pike-ptg-future

6. Hierarchical image access
Very lively discussion around this, in particular, whether this type of
sharing can be accommodated by our current image sharing framework.
nikhil is going to put up a spec to clarify the proposal and use cases,
and the team agreed to continue the discussion on the spec patch.

7. OSSN review
By this time we were running late, so we didn't get too far.  We
concentrated on OSSN-0075, in which we provide operator advice, but for
which we don't have a fix.  In a nutshell, the problem is that Glance
allows a user to specify an image UUID at the time of image creation.
If an operator purges the database to eliminate all soft-deleted
records, it's possible for a UUID for a trusted image to be re-used by
some other image.  We discussed introducing a policy to govern
specifying a UUID on image creation and/or modifying the glance-manage
script to purge image properties, tags, members, and locations but no
longer purge the main images table, which would prevent UUID re-use
since we'd retain all the issued UUIDs.  There are pros and cons to both
approaches.  Consensus was to consult with a database expert, and
possibly both introduce the policy and modify the purge operation and
let operators choose whether/how they want to handle this issue.


Looking forward to another productive day!
brian