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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
