Open Stack

Hello Glancers,

Due to technical difficulties, today's virtual midcycle was not
recorded.  So here's a summary of the discussion; refer to the etherpad
for each session for more details, and feel free to ask for
clarifications in #openstack-glance or here on the ML.

A link to the etherpads for each of the six sessions discussed below can
be found here:
https://etherpad.openstack.org/p/glance-pike-virtual-midcycle


1. Ideas for encouraging new contributors
=========================================

We began with a quick discussion of the recent events that appear to
have wiped out a large number of Glance cores.  It was mentioned at the
TC meeting earlier this week that Glance might have to go into
status:maintenance-mode, but we'd like to try to avoid that.  While you
could look at maintenance mode as a signal that the project needs more
help, it could also be perceived by prospective new contributors as a
reason not to work on Glance, and hence would be counterproductive with
respect to attracting new people to work on Glance.  In any case, we
decided to wait until after the summit when we should have a better idea
of what kind of developer resources Glance has.

We need a statement somewhere (maybe on the standing meeting agenda)
explaining the weekly priority emails, in two respects:

(a) The priorities listed aren't the only things that get attention in
any given week; the idea is that core reviewers should make sure the
priority items have all been reviewed before looking at other patches.

(b) The priorities for the week are set at the weekly Glance meeting.
So the way to get an item on the list is to make sure it's brought up
when priorities are discussed at the meeting, which in turn implies that
you should be present at the weekly meeting.

A strategy we'll try out to encourage new contributors is to have a
second weekly meeting attended by all the core reviewers, who will be
available at that time to answer questions about patches.  If no one
shows up, we can just work through the backlog of patches.  (Another
idea is that this weekly meeting could alternate between reviews and
bugs.)  This will start after the summit.

Finally, Nikhil and Erno (and possibly Flavio) will be at the Glance
on-boarding session during lunch on Monday at the summit (12:45-2:00),
so hopefully we can pick up some new contributors there.


2. How the $*@# are we going to complete image import?
======================================================

This went much differently than I expected.  You can see the proposal
for an "economy-class" import outlined on the session etherpad, but Erno
made a convincing argument that we should stick with the current plan
and that an MVP can be completed in Pike (given other appropriate
adjustments to the Pike priorities).  So that's what we'll do.  Pike
will ship with import "off" so that there's no impact on deployers who
aren't interested in it yet.


3. A proposal for dealing with OSSN-0075
========================================

We discussed a proposal to introduce a new policy that would restrict
the ability to specify an image_id at the time an image is created.
Objections were that it's a breaking change, and that not having this
feature widely available would be a pain point for hybrid cloud use cases.

What we settled on was to modify the glance-manage db purge function to
purge images marked deleted *except* for those with 'public' visibility,
since those are the images that would most likely be attacked by this
exploit.  They're also likely to be a minority of images, especially
since the advent of community images in Ocata.

I'll write up a spec lite so that we can get more discussion on this
idea, and make sure it's publicized to the operators' list and security
team to get a wide set of comments.


4. What's remaining for zero-downtime upgrades, and what's our plan to
make it happen?
===============

The dev docs explaining how to write the migrations have been completed.

We need to review/revise the operator docs explaining how to perform a
zero-downtime database migration.

Asserting the tags requires having upgrade tests in the gate.  There's
not likely going to be any bandwidth for working on this in Pike, so we
won't worry about trying to assert the tags until Queens.


5. Last chance for Pike specs
=============================

We have some good specs proposed for Pike, but it's not clear anymore
that there will be anyone to work on them.  We'll add an 'untargeted'
directory to the specs repo for specs that have been approved but not
implemented (so that they'll all be in one place; now you have to crawl
each previous release to find the approved-but-not-implemented specs).

See the specs review etherpad for more details; each spec proposed for
Pike has an "action" associated with it that describes what we decided
today.  (I'll get patches up in the next day or so completing the
"actions" and moving the specs around in the repo.)


6. Finalizing the priorities for Pike
=====================================

I'll be putting up a patch to the specs repo, but here's a quick summary:

The Pike priorities are:
(1) image import refactor
(2) complete rolling upgrades (to the extent discussed above)

What's being deprioritized (had been proposed as priorities at the PTG):
(3) documentation reorganization (will have to be postponed)
(4) OpenStack community goals: py35 is pretty much completed, but we're
not going to work on the wsgi goal


Again, links to the session etherpads can be found here:
https://etherpad.openstack.org/p/glance-pike-virtual-midcycle

Sorry that the plan to record the virtual midcycle did not work out.


cheers,
brian