Sign up or log in to bookmark your favorites and sync them to your phone or calendar.

Design Summit [clear filter]
Wednesday, April 17


Calling all Interns and Mentors: Ideas to improve
We know there's always a time crunch, but we want to find good ways to bring in newcomers like interns during the time frame of their availability as students and the open windows for coding. There's a lot of needed bug triage in all the projects, would interns be interested in fixing bugs for the entire internship? How about interns for QA, doc, infrastructure, is there a need and does that fit better with the timeframes we have? Let's discuss ways to improve our internship programs across multiple projects. We'll bring our experiences from the GNOME Outreach Program for Women. We can also brainstorm ways to strengthen our Google Summer of Code application.

(Session proposed by Anne Gentle)

Wednesday April 17, 2013 1:50pm - 2:30pm


Python3 in OpenStack
Eventually, Python3 projects should be supported in OpenStack. We can't do this all in Havana, but we can get a start.

This session seeks to organize the efforts of the projects toward Python3 compatibility and to identify how and where we can and should ask for help from the Foundation, TCs, and the library, infrastructure projects.

(Session proposed by Eric Windisch)

Wednesday April 17, 2013 2:40pm - 3:20pm


Stable Branch
The Grizzly cycle was the third cycle where we maintained a stable branch for the previous release. We will look back over the stable/folsom maint efforts and identify successes and failures.

The stable-maint process still has some rough edges and so we will discuss ideas for improvements, ideally setting some specific goals for stable/grizzly maintenance.

(Session proposed by Mark McLoughlin)

Wednesday April 17, 2013 3:40pm - 4:20pm


Vulnerability management: infra needs, scoring...
This session will be focused on improvements to the Vulnerability Management process.

In particular we'll review infrastructure plans to better support the Vulnerability Management Team (VMT) workflow (simplified and more reliable patch testing, patch review/approval...), as well explore the option of rating the vulnerabilities (CVSS scoring...).

If there is time remaining, we'll look into other improvements we could make to the process.

(Session proposed by Thierry Carrez)

Wednesday April 17, 2013 4:30pm - 5:10pm


Technical Committee membership evolution
The Technical Committee is a representation of the technical contributors to the OpenStack project, tasked with solving cross-project issues, serve as appeals board and consider new projects for inclusion. The membership is currently set to all PTLs + 5 directly-elected members.

This session is a workshop to discuss future evolution of this membership for the "I" cycle, with two goals in mind: avoid committee bloat as we grow the number of projects in OpenStack, and have good representativity.

(Session proposed by Thierry Carrez)

Wednesday April 17, 2013 5:20pm - 6:00pm
Thursday, April 18


Continuous-deployment for upstream Openstack
Continuous deployment - the production version of the well known continual integration process - is very appealing to large deployers: it reduces the time to roll out security patches and reduces the risk of each production push.

However, CD isn't something that can be bolted on - like CI it requires the upstream code change process to support it (for instance, with CI the test suite has to be fast enough to run per-commit).

With CD trunk has to be always deployable, be able to run stably with skewed service versions and for DB migrations to be extremely fast.

In this session I want to get the ball rolling on us stepping up to CD from our current CI system, for at least all the core projects.

I expect this to involve assessing how much interest there is from contributors, as well as technical discussion on the logistics and overheads of delivering a CD ready trunk.

(Session proposed by Robert Collins)

Thursday April 18, 2013 9:00am - 9:40am


Dependency Management
In light of the recent threads and issues surrounding PyPI, openstack/requirements and version pinning, I'd like to discuss dependency management as it relates to OpenStack froma much higher vantage point. I think we need to go all the way back to use cases and requirements and set them out very clearly. Then, armed with that, we can assess various technology solutions for dealing with them both for CI and for people consume our software.

(Session proposed by Monty Taylor)

Thursday April 18, 2013 9:50am - 10:30am


Sorting out test runners, wrappers and venvs
We've gotten ourselves into a pickle. Across the projects, we have a combination of tox and run_tests.sh and some projects have migrated to testr from nose and some havent. People are confused about how to run tests, and about how jenkins runs tests - especially since most projects have at least 2 different ways IN THE TREE.

We need to sit down, in a room, make a actual plan for moving forward, and then do it.

(Session proposed by Monty Taylor)

Thursday April 18, 2013 11:00am - 11:40am


Failure management in the gate
In the grizzly run up we had a few really bad days where gate resets were fast and furious, and it would take, on average, 6 or 8 hours to merge. This led us to a conversation where the nova dev team was seriously considering turning off the gate checking entirely.

This session would be on brainstorming the ways to find and get to the bottom of failures in the gate faster, and hopefully reduce them over time.

It would include:
* ways to optimize gate resets. When we know a test has failed, can we reset early, instead of waiting for the train wreck to complete?
* ways to get to the bottom of fails fast - the recheck page was a good start, but it turned out to be pretty static info, and people really corrupted the data by picking bugs poorly
* ways to analyze fails (some sort of failure dashboard), figure out the infra restriction on tooling for this.
* ways to alert users so the answer to "is there a problem" isn't keep an -infra tab open and scroll back.

(Session proposed by Sean Dague)

Thursday April 18, 2013 11:50am - 12:30pm


Bare Metal Testing
This session will include the following subject(s):

Bare Metal Testing:

Discussion around testing full-bare metal deploys on every commit. We've got a lot of other stuff figured out at this point, and we got bare metal stuff in nova for grizzly - we need to test it, and test using it.

(Session proposed by Monty Taylor)

refstack - a description of an OpenStack cloud:

Recent discussions around FITS testing led to the idea of a thing called "refstack", which would allow us to describe and deploy a reference OpenStack against which we can test. There have been some discussions on implementation, with the leading contended being a heat template which has a clear api contract with the nodes it's creating and the metadata it's going to pass them, such that various technologies (chef, puppet, juju) could be designed to expect the same per-node metadata. However, we should probably actually talk about that in person.

(Session proposed by Monty Taylor)

Thursday April 18, 2013 1:30pm - 2:10pm


OpenStack CI logging
OpenStack continuous integration generates a fair amount of logs. Devstack, tempest, and testr are quite verbose in what they have done. This information is very valuable, but is also very dense. Let's discuss which logs are important, how long they should be archived for, how they should be archived, and how they should be indexed.

Current ideas are that we might try to archive six months of logs and use logstash/elasticsearch to index a smaller subset of the logs. However, this is not set in stone and feedback will be very useful hence this design session.

This session is motivated by the recent issues with the log server running out of disk space and disagreement on which logs we actually need. The infra team wants to make sure we are logging information that is useful.

(Session proposed by Clark Boylan)

Thursday April 18, 2013 2:20pm - 3:00pm


Review of non-infra-managed tooling
A number of tools we use (and run on our infrastructure) are not under direct Core Infrastructure team management. We should review them and see if they are still necessary, what is the plan to bring them under control (if any), and what improvements can be made to them over the next cycle.

This includes:
* Release status, bugdaystats
* openstack.org website
* ...

(Session proposed by Thierry Carrez)

Thursday April 18, 2013 3:20pm - 4:00pm


Projects (re)naming
We have two names for each of our projects. One is the official name ("OpenStack Compute") and the other is the codename ("Nova").

Codenames have a number of drawbacks: we don't actively protect their trademark, they are confusing to newcomers, and they tend to shadow their more official counterparts. But codenames also have benefits: they are highly-convenient short names (to be used in conversations, executables, modules...), and they separate the project itself from its functional scope, so they remain valid even if that scope evolves.

This session is about whether we should proactively drop usage of codenames in OpenStack, or reduce our dependency over them, or just keep them the way they are. In case of a trademark attack, should we switch to another codename, or abandon usage of a codename and switch to some short version of the "official" name ? Finally, we'll look at how we should proceed to fully rename a project.

(Session proposed by Thierry Carrez)

Thursday April 18, 2013 4:10pm - 4:50pm


Havana release schedule
Let's review the proposed schedule for the Havana cycle, as well as any potential changes in freezes, intermediary milestones, release candidates management, etc.

(Session proposed by Thierry Carrez)

Thursday April 18, 2013 5:00pm - 5:40pm