Loading…
OpenStack Kilo Design Summit has ended
This is the schedule for the Kilo Design Summit, where OpenStack contributors discuss the future of OpenStack development.
Click here for the main OpenStack Summit conference schedule.

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

Cross-project workshops [clear filter]
Tuesday, November 4
 

11:15 CET

API Working Group (Part 1)
The API Working Group's purpose is to propose, discuss, review, and advocate for API guidelines for all OpenStack Programs to follow. In this session we'll be discussing the API Working Group ( https://wiki.openstack.org/wiki/API_Working_Group ) itself, including reviewing sections on the wiki page, our processes, and how we can be an effective working group.

Etherpad: https://etherpad.openstack.org/p/kilo-crossproject-api-wg

Session Lead: Jay Pipes, Everett Toews


Tuesday November 4, 2014 11:15 - 11:55 CET
Manet

11:15 CET

DefCore, RefStack, Interoperability, and Tempest
Session Leads: David lenwell, Catherine Diep, Rocky Grober


Tuesday November 4, 2014 11:15 - 11:55 CET
Degas

12:05 CET

API Working Group (Part 2)
The API Working Group's purpose is to propose, discuss, review, and advocate for API guidelines for all OpenStack Programs to follow. In this session we'll discuss pain points and inconsistencies in the OpenStack APIs and propose guidelines to improve those problems. To be concluded on Thursday in http://kilodesignsummit.sched.org/event/3f0a5f22f2d641ef69965373f3e23983

Etherpad: https://etherpad.openstack.org/p/kilo-crossproject-api-wg

Session Lead: Jay Pipes, Everett Toews


Tuesday November 4, 2014 12:05 - 12:45 CET
Manet

12:05 CET

Common Approach to HA
Let's try and get some agreement on what projects should do (and hopefully backed by tests) to make services behave correctly from a cluster manager's perspective.

Etherpad: https://etherpad.openstack.org/p/kilo-crossproject-ha-integration

Session Lead: Angus Salkeld


Tuesday November 4, 2014 12:05 - 12:45 CET
Derain

12:05 CET

Moving Functional Tests to Projects
Our current methodology of using tempest to house functional tests which are run against all projects on every commit has several problems
* It puts the testing focus for all projects on the tempest team which is not scalable
* There is not time to run deep functional tests because too much time is spent running tests against projects that cannot be affected
The move to per-project functional testing, combined with more aggressive post-merge testing, will make catching bugs per-commit more likely
and reduce the chance that bad code slipping in to some project will impact the gate stability for other projects. Some issues that need resolution:
* How do we retain the ability to export a functional test suite for OpenStack as a whole, the way tempest is used now? This is important for
refstack and any one else doing validation.
* What kinds of non-scenario, non-integration tests remain in tempest?
** None?
** Some coverage for API stability?
* How do we make sure projects do their testing in a consistent way? Do they need to?
* Where do two-project integration tests live?

Session Lead: David Kranz


Tuesday November 4, 2014 12:05 - 12:45 CET
Degas

14:00 CET

Consistent Approach to Upgrades and Versioning
Etherpad: https://etherpad.openstack.org/p/kilo-crossproject-upgrades-and-versioning

Let's explore the soon to be oslo-versioned-objects and what it can (and can't) provide a project in terms of supporting upgrades.

Session Leads: Angus Salkeld, Dan Smith


Tuesday November 4, 2014 14:00 - 14:40 CET
Derain

14:00 CET

Schema and Schema Validation for Notifications
Notifications emitted from OpenStack Services have a small number of required fields: event_type, timestamp and priority. The rest goes in an undefined "payload" section. As OpenStack has grown we've seen the need to enforce the schema of these payload sections as well as establish some consistency rules for notifications. This session will define a plan for implementing this schema validation as well as how to deprecate the old notification scheme (or provide an alternative). The challenge to migration is updating all the code in all the OpenStack services which hand-crafts the payload data. What will happen to existing downstream systems that expect the current format?

Session Leads: Sandy Walsh, Julien Danjou


Tuesday November 4, 2014 14:00 - 14:40 CET
Degas

14:00 CET

Specs: The Good, Bad, and the Ugly
Most projects have adopted a new process where we use gerrit to review design specifications associated with blueprints. After using this process for the Juno release, we should get back together and discuss what is going well or not so well. We can discuss potential changes and opportunities for standardizing the approach across projects. Finally, we can also discuss the addition of a cross-project specs repo for the Kilo release.

Session Lead: John Garbutt


Tuesday November 4, 2014 14:00 - 14:40 CET
Manet

14:50 CET

Approaches for Scaling Out
Nova has had support for Cells for several releases now. There is another approach, Cascading, that has been recently proposed. Let's quickly recap cells and then discuss the cascading alternative.

Session Leads: John Garbutt, Chaoyi Huang


Tuesday November 4, 2014 14:50 - 15:30 CET
Manet

14:50 CET

Changes to our Requirements Management Policy
As we move to testing lots of projects under a devstack configuration, and possibly reduce the integrated release scope, we need to support requirements from projects that are not integrated. These projects need to use a common set of dependencies to allow them to be installed together for deployment, even if they are not tested together in our gate.

Session Lead: Doug Hellmann


Tuesday November 4, 2014 14:50 - 15:30 CET
Derain

14:50 CET

Scaling Documentation Across Projects
To borrow from the mailing list thread at http://lists.openstack.org/pipermail/openstack-dev/2014-October/047801.html "The current system is something of a hybrid model - for some subset of official projects considered "important", the Docs team is directly responsible; for the others, the project team has to write the documentation. The docs team is available to provide support and tools for other official projects." Some questions for discussion:

Project liasons, what should they do? The OpenStack Documentation is centralized on docs.openstack.org but often there's a need for specialty information when reviewing patches or triaging doc bugs. A doc liaison should be available to triage doc bugs when the docs team members don't know enough to triage accurately, and be added to doc reviews that affect your project. You'd be notified through email when you're added either to a doc bug or a doc review. We also would appreciate attendance at the weekly doc team meeting, We meet weekly in #openstack-meeting every Wednesday at alternating times.

Do project teams want a Documentation team as advisory? What expectations do you have from the Docs team?

How should the Docs team engage projects that are not already writing user/operator/API docs? How to get integrating teams better docs faster?

How should we write, review, and publish integrated documentation?

Session Lead: Anne Gentle


Tuesday November 4, 2014 14:50 - 15:30 CET
Degas

15:40 CET

End user experience, SDKs
In a recent large discussion about development priorities in OpenStack, a major theme was improving end user experience. Let's discuss some ideas of things that could be accomplished in Kilo to improve the situation.

Session Lead: Monty Taylor


Tuesday November 4, 2014 15:40 - 16:20 CET
Derain

15:40 CET

How to Tackle Technical Debt in Kilo
Session Lead: Mark McClain


Tuesday November 4, 2014 15:40 - 16:20 CET
Manet

15:40 CET

Log Rationalization
https://etherpad.openstack.org/p/kilo-crossproject-log-rationalization

Session Lead: Sean Dague


Tuesday November 4, 2014 15:40 - 16:20 CET
Degas

16:40 CET

Growth Challenges (Part 1)
After four years of continued expansion, the OpenStack project is encountering new growth challenges. Those call for rapid and aggressive solutions to ensure that we keep on growing and adapt to an ever-changing world in the future. In this cross-project workshop we'll explore various growth challenges (scaling core teams inside projects, scaling the gate, scaling the horizontal teams, how to get competition without duplication...), brainstorm solutions, and expose the current proposed reforms (big tent, layer 1...).



Tuesday November 4, 2014 16:40 - 17:20 CET
Manet

16:40 CET

Keystone Feature Adoption
Keystone has introduced a number of new features over time. Many of these features are never consumed by the other services in the OpenStack ecosystem. For the features that are meant to be utilized by the other services, we need to have a clear path to drive adoption. What are the short term and long term plans for consuming these features? A specific focus on the following:

Etherpad: https://etherpad.openstack.org/p/kilo-crossproject-keystone-feature-adoption

Session Leads: Jamie Lennox, Morgan Fainberg


Tuesday November 4, 2014 16:40 - 17:20 CET

17:30 CET

Growth Challenges (Part 2)
After four years of continued expansion, the OpenStack project is encountering new growth challenges. Those call for rapid and aggressive solutions to ensure that we keep on growing and adapt to an ever-changing world in the future. In this cross-project workshop we'll explore various growth challenges (scaling core teams inside projects, scaling the gate, scaling the horizontal teams, how to get competition without duplication...), brainstorm solutions, and expose the current proposed reforms (big tent, layer 1...).



Tuesday November 4, 2014 17:30 - 18:10 CET
Manet

17:30 CET

Larger Policy Discussion
Etherpad: https://etherpad.openstack.org/p/kilo-crossproject-larger-policy-discussion

OpenStack's policy (rule engine and enforcement implementation) has served us reasonably well, but it is hard to work with and each deployment of OpenStack can have a very different rule-set on what a given role means. In order to provide for a better user experience in tools like the Dashbard, and to offer more fine-grained authorization abilities, we need to be able to answer the following things for any OpenStack deployment: What can I do with role X? To perform action Y, what role(s) do I need?

Session Leads: Morgan Fainberg, Nathan Kinder, Adam Young



Tuesday November 4, 2014 17:30 - 18:10 CET
Degas