Loading…
This event has ended. View the official site or create your own event → Check it out
This event has ended. Create your own
View analytic

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

Monday, May 12
 

11:15am

Ops Meetup: Ask the devs: Meet the PTLs and TC; How to get the best out of the design summit
To kick off the Operators meetup, meet some of the PTLs and TC members, ask them questions and hear about how to get the best out of the Design Summit as an experienced OpenStack Operator.

The Ops Meetup, organized by the User Committee, is a new track comprised of collaborative, working sessions for people who are operating OpenStack clouds (and contributors who want to hear from them). The purpose is to share knowledge and best practices among cloud operators, as well as provide feedback based on experience running OpenStack. The aim of the feedback is to assist the development community in their planning of future releases, ensuring a wide range of operational scenarios are taken into account when architecting new features.  There will be no formal presentations, and a moderate level of knowledge around running OpenStack is assumed. If you're just starting out, the Operations Track [http://openstacksummitmay2014atlanta.sched.org/overview/type/operations] will be much more friendly! 

Monday May 12, 2014 11:15am - 11:55am
B308

12:05pm

Ops Meetup: Reasonable Defaults
Lots of us complain about default settings; lets identify the ones that hurt and propose fixes.

The Ops Meetup, organized by the User Committee, is a new track comprised of collaborative, working sessions for people who are operating OpenStack clouds (and contributors who want to hear from them). The purpose is to share knowledge and best practices among cloud operators, as well as provide feedback based on experience running OpenStack. The aim of the feedback is to assist the development community in their planning of future releases, ensuring a wide range of operational scenarios are taken into account when architecting new features.  There will be no formal presentations, and a moderate level of knowledge around running OpenStack is assumed. If you're just starting out, the Operations Track [http://openstacksummitmay2014atlanta.sched.org/overview/type/operations] will be much more friendly!

Monday May 12, 2014 12:05pm - 12:45pm
B308

2:00pm

Ops Meetup: Upgrades and Deployment Approaches
Session to discuss upgrades, packaging and deployment in general.

The Ops Meetup, organized by the User Committee, is a new track comprised of collaborative, working sessions for people who are operating OpenStack clouds (and contributors who want to hear from them). The purpose is to share knowledge and best practices among cloud operators, as well as provide feedback based on experience running OpenStack. The aim of the feedback is to assist the development community in their planning of future releases, ensuring a wide range of operational scenarios are taken into account when architecting new features.  There will be no formal presentations, and a moderate level of knowledge around running OpenStack is assumed. If you're just starting out, the Operations Track [http://openstacksummitmay2014atlanta.sched.org/overview/type/operations] will be much more friendly!

Monday May 12, 2014 2:00pm - 2:40pm
B308

2:50pm

Ops Meetup: Architecture Show and Tell, Tales and Fails
Short, lightening-talk-like presentations of architectures with a small amount  of discussion, interspersed with tales of things that went horribly wrong. Looking at not just the OpenStack bits too but how to deliver an end-to-end cloud service with OpenStack building blocks.

The Ops Meetup, organized by the User Committee, is a new track comprised of collaborative, working sessions for people who are operating OpenStack clouds (and contributors who want to hear from them). The purpose is to share knowledge and best practices among cloud operators, as well as provide feedback based on experience running OpenStack. The aim of the feedback is to assist the development community in their planning of future releases, ensuring a wide range of operational scenarios are taken into account when architecting new features.  There will be no formal presentations, and a moderate level of knowledge around running OpenStack is assumed. If you're just starting out, the Operations Track [http://openstacksummitmay2014atlanta.sched.org/overview/type/operations] will be much more friendly!

Monday May 12, 2014 2:50pm - 4:20pm
B308

4:40pm

Ops Meetup: Networking
We’ll discuss networking issues and questions, such as what do you think about Neutron vs nova-network?

The Ops Meetup, organized by the User Committee, is a new track comprised of collaborative, working sessions for people who are operating OpenStack clouds (and contributors who want to hear from them). The purpose is to share knowledge and best practices among cloud operators, as well as provide feedback based on experience running OpenStack. The aim of the feedback is to assist the development community in their planning of future releases, ensuring a wide range of operational scenarios are taken into account when architecting new features.  There will be no formal presentations, and a moderate level of knowledge around running OpenStack is assumed. If you're just starting out, the Operations Track [http://openstacksummitmay2014atlanta.sched.org/overview/type/operations] will be much more friendly!

Monday May 12, 2014 4:40pm - 5:20pm
B308

5:30pm

Ops Meetup: Security
We will discuss the following questions and more:
  • What should any cloud be doing (and can we make this default)?
  • How does an operator address an auditor ?
  • What tools can we recommend ?

The Ops Meetup, organized by the User Committee, is a new track comprised of collaborative, working sessions for people who are operating OpenStack clouds (and contributors who want to hear from them). The purpose is to share knowledge and best practices among cloud operators, as well as provide feedback based on experience running OpenStack. The aim of the feedback is to assist the development community in their planning of future releases, ensuring a wide range of operational scenarios are taken into account when architecting new features.  There will be no formal presentations, and a moderate level of knowledge around running OpenStack is assumed. If you're just starting out, the Operations Track [http://openstacksummitmay2014atlanta.sched.org/overview/type/operations] will be much more friendly!

Monday May 12, 2014 5:30pm - 6:10pm
B308
 
Tuesday, May 13
 

11:15am

Barbican Events
The goal of this session is to discuss the use cases and design for an eventing system in Barbican. Eventing will be used to solve for several use cases including auditing, billing, notifications / ticketing and integration with other OpenStack projects like Ceilometer.

(Session proposed by Jarret Raim)


Tuesday May 13, 2014 11:15am - 11:55am
B306

11:15am

Consistency across Openstack REST APIs
With the number of Openstack projects growing there are now many
Openstack REST APIs in development. We should aim to have some minimum
level of consistency with how our REST APIs look to our users. This
would be a discussion to cover topics such as:

- Developing common REST API design standards and nomenclature across OpenStack Projects
- Guidance for new projects
- How do we slowly converge towards a common standard?
- Extensions or no extensions?
- Recommendations for common REST API frameworks
- How to handle backwards incompatible changes and major revisions to APIs
- How are projects currently doing this and what impact does it have on users?
- What is our policy when we make mistakes and don't find out for a while and how does this affect continuous deployment
- eg accidental backwards incompatible changes
- Should all new API's be experimental for once cycle (no guarantees around backwards incompatible changes



(Session proposed by Christopher Yeoh)


Tuesday May 13, 2014 11:15am - 11:55am
B303

11:15am

Solum, Murano, Heat: how to handle app lifecycle ?
A number of projects are looking at going up the stack and handle application workload lifecycle management. This workshop aims at placing them all in the same room and creating opportunities for convergence in the future.

(Session proposed by Thierry Carrez)


Tuesday May 13, 2014 11:15am - 11:55am
B302

11:15am

The Future of Python Support
This session combines discussions about deprecating old versions of Python (2.6) with plans for supporting newer versions (3.3 and beyond). The expected outcome is a decision about dropping support for 2.6 (including a plan if we decide to drop it), a status update on the ongoing work to port to Python 3.3, and a report from the language summit at PyCon about upcoming changes to the language.

(Session proposed by Doug Hellmann)


Tuesday May 13, 2014 11:15am - 11:55am
B304

11:15am

Design Summit 101

Is this your first OpenStack Design Summit? Unlike most conferences, you are invited to participate and play an active role. But... where to start? The rationale and the organization that allows such a unique collaborative design will be explained. This is your chance to get answers and get the best of it!

During this session we will let the attendants know some details about the Design Summit, including who will be attending, different tracks and purposes, which sessions/talks are the most suitable for beginners and how they can participate. This short introduction will be followed by a a lively presentation of the most common situations and how to behave when facing them. It will be a miniature experience of a first participation to the Design Summit.


Tuesday May 13, 2014 11:15am - 11:55am
B305

11:15am

Ironic Python Agent
There is work being done to use an agent model to provision servers with Ironic. Development is moving rapidly. We want to discuss the scope of the project, the capabilities it needs, and options for building and running PXE images with the agent.

We'll spend 10 minutes going over the agent architecture and code layout, and open the remaining time for discussion.

Wiki: https://wiki.openstack.org/wiki/Ironic-python-agent
Code: https://github.com/openstack/ironic-python-agent
Driver code: https://review.openstack.org/#/c/84795/


Etherpad: https://etherpad.openstack.org/p/juno-summit-ironic-python-agent

(Session proposed by Jim Rollenhagen)


Tuesday May 13, 2014 11:15am - 11:55am
B301

12:05pm

Kite
The kite project has landed most of its initial implementation. This session will focus on a review of the use cases and goals of the kite project as well as the proposed implementation. The goal of this session is to ensure that the Barbican core reviewers understand the Kite project enough to provide meaningful review for future PRs.

(Session proposed by Jarret Raim)


Tuesday May 13, 2014 12:05pm - 12:45pm
B306

12:05pm

Consistency across Openstack REST APIs (part 2)
Part 2 of "Consistency across Openstack REST APIs".

This is an extension of the previous session. This topic was granted two time slots.

(Session proposed by Russell Bryant)


Tuesday May 13, 2014 12:05pm - 12:45pm
B303

12:05pm

Cross-project Documentation
We have different docs for different audiences:
cross-project docs for deploy/install/config: openstack-manuals
API docs references, standards: api-site and others

These are written with the git/gerrit method. I want to talk about standing up a new docs site that serves these types of people with these requirements:

Experience:
Solution must be completely open source
Content must be available online
Content must be indexable by search engines
Content must be searchable
Content should be easily cross-linked by topic and type (priority:low)
Enable comments, ratings, and analytics (or ask.openstack.org integration) (priority:low)

Distribution:
Readers must get versions of technical content specific to version of product
Modular authoring of content
Graphic and text content should be stored as files, not in a database
Consumers must get technical content in PDF, html, video, audio
Workflow for review and approval prior to publishing content

Authoring:
Content must be re-usable across authors and personas (Single source)
Must support many content authors with multiple authoring tools
Existing content must migrate smoothly
All content versions need to be comparable (diff) across versions
Content must be organizationally segregated based on user personas
Draft content must be reviewable in HTML
Link maintenance - Links must update with little manual maintenance to avoid broken links and link validation

(Session proposed by Anne Gentle)


Tuesday May 13, 2014 12:05pm - 12:45pm
B304

12:05pm

Solum, Murano, Heat: app lifecycle (part 2)
Part 2 of "Solum, Murano, Heat: how to handle app lifecycle ?".

This is a continuation of the previous session. This topic was granted 2 time slots.

(Session proposed by Russell Bryant)


Tuesday May 13, 2014 12:05pm - 12:45pm
B302

12:05pm

Ironic Performance and Scalability
This session will cover efforts by multiple teams to begin profiling Ironic's performance and scalability, and identifying areas that need improvement.

* Does Ironic's code scale to hundreds of conductors and tens of thousands of nodes? What about Ironic's interaction with other services?
* What bottlenecks do we hit when deploying to bare metal in parallel? What limitations do we hit with network and disk IO, IPMI latency and instability, etc? What recommendations can we make to deployers to mitigate these?
* What optimizations can be done to minimize the end-to-end time to boot a single bare metal machine? Are they worth the investment?

The session will be co-presented by Mirantis, Rackspace, and HP.

https://etherpad.openstack.org/p/juno-summit-ironic-performance

This session will include the following subject(s):

Benchmarking Ironic:

Let's discuss the following aspects of benchmarking Ironic:

- Measuring API performance (easy)
- Ironic Nova interaction
- Ironic neutron interaction
- Provisioning nodes. This might be useful for owners of a specific hardware.

(Session proposed by Roman Prykhodchenko)

Deploying as fast as possible:

Today Ironic can deploy a server in around 22 minutes (citation needed). We can do better than this. Let's talk about strategies to speed up deployments to less than 10 minutes, or ideally the same speed as Nova. Here's some ideas to get us started:

* Caching popular images on boot devices
* Leaving servers powered on and ready to be deployed to
* Using kexec instead of reboot

What else can we come up with?

(Session proposed by Jim Rollenhagen)

Running Ironic at scale:

Ironic is still in its infancy. The architecture is pretty good, the HA model should work well, and the API is fairly fast. However, nobody is running it at scale yet, and there could be problems yet to be uncovered.

Let's take a deep dive into Ironic's architecture and talk about how it might be improved to support large deployments. We could cover items such as:

* Hash ring mapping - how to find nodes for a conductor more efficiently
* Making API calls more async - Nova doesn't ever wait for an RPC response - why does Ironic?
* Making the conductor more efficient - today the conductor can easily be overloaded with work - are there ways to make this better besides spinning up more conductors?
* Imaging efficiency - how can many machines be provisioned at once without saturating Glance or the network itself?

Or any other topics folks want to cover.

(Session proposed by Jim Rollenhagen)


Tuesday May 13, 2014 12:05pm - 12:45pm
B301

12:05pm

Designate - Juno Design Session
Discuss the plans for Designate's Juno Cycle

(Session proposed by Graham Hayes)


Tuesday May 13, 2014 12:05pm - 12:45pm
B305

12:45pm

Lunch
Tuesday May 13, 2014 12:45pm - 2:00pm
Expo Hall, Level 1

2:00pm

Dealing with changes of plans, rejections and more
It can happen that a team accepts a big idea and makes long term plans to implement it. During a "long" time things happen and maybe the plan needs to change, even if it already started its implementation and even if it's close to being done.

Sometimes it happens that even small changes, features or other contributions, get rejected after they were approved.

Sometimes a change is submitted with high hopes by an innocent soul and a cruel -2 with a one-liner comment squashes, destroys, annihilates a soul.

How shall we as a community deal with change of plans, rejections, annoying people, annoying processes? Where can/shall people go to express frustration, happiness, complaints and praises?

(Session proposed by Stefano Maffulli)


Tuesday May 13, 2014 2:00pm - 2:40pm
B302

2:00pm

Easier documentation for all project developers
Nobody WANTS to submit code without documentation, but when adding to the docs takes as much work as writing the code, it's inevitable that the docs will go wanting. On the other side of the coin, the docs team wants to provide great documentation, but without being able to read the developer's mind, it's not always easy (or even possible). This session will look at some ways we can make it easier for developers to contribute code, and perhaps more important, what it will take to motivate them to do it.

We hope to come away with at least the seed of a process that we can put into place during the Juno cycle so that developers are motivated and able to provide at least the seeds of documentation that the docs team can then work into the actual manuals.

(Session proposed by Nicholas Chase)


Tuesday May 13, 2014 2:00pm - 2:40pm
B304

2:00pm

New Oslo Library Releases and Your Project
The Oslo program will be releasing several new libraries during Juno. During this session we will go over the release plan discuss how to make the transition go as smoothly as possible.

(Session proposed by Doug Hellmann)


Tuesday May 13, 2014 2:00pm - 2:40pm
B303

2:00pm

Graffiti - The Cloud Capability Service
In this technical session, we will talk about Graffiti, a new cloud capability project that HP and Intel have started working on and we invite your participation. The intent of Graffiti is for OpenStack users to be able to declare the capabilities and service level objectives they require at a higher, more portable way than they do today. The system will then guide the selection of lower level cloud resources that match the desired capabilities.

Various OpenStack services have introduced techniques to abstract some of the low level resource selection to one level higher (such as flavors or volume types). While powerful, a challenge that we’ve experienced with OpenStack is that the way resource types and resource instances get exposed and discovered across services makes usage and remapping across deployments a manual and error prone process. Graffiti provides a common methodology to describe resource capabilities in the cloud which we believe can then be leveraged by other projects such as Horizon, Nova, Heat, scheduling, reservation, and policy enforcement to enable better cross service collaboration and consistency.

We will be showing a proof of concept demo in Horizon that crosses Nova, Glance, and Cinder. We would then like to discuss with the community where Graffiti can best fit in to the ecosystem and how it may relate to other projects and use cases.

(Session proposed by Travis Tripp)


Tuesday May 13, 2014 2:00pm - 2:40pm
B305

2:00pm

Mistral - Workflow as a Service POC status
Mistral team completed a POC for the workflow service. This POC covers an initial version of Mistral DSL to define tasks and transitions between them and Mistral engine with its main concept implemented. There is a huge discussion in the community about the right set of technologies which should be used for workflows orchestration\execution.
Using the POC code we want to show how customer use cases listed on Mistral wiki can be implemented with Mistral approach. Also we want to show requirements to engine raised during POC implementation. These requirements will be used to find out how the taskflow library can be used to implement Mistral engine functionality.

(Session proposed by Georgy Okrokvertskhov)


Tuesday May 13, 2014 2:00pm - 2:40pm
B306

2:00pm

Refstack Overview and Deep Dive
Refstack is a suite of interoperability verification test tools and a compliance test set for OpenStack service and product vendors.

Refstack provides official testing channels and hosted scorecards on refstack.org. In addition, RefStack includes a command line interface and a way to run a local copy of the RefStack website internally on your cloud installation. Private cloud builders can run the tests internally to generate scorecards for clouds that do not have API endpoints that refstack.org can reach.

Refstack uses the official OpenStack testing tool, Tempest, as its test engine. The definition of core and "must pass" criteria will be defined by the DefCore committee.

In this session, we will discuss RefStack, its purpose, architecture, operation and Q&A.

Links:
http:/refstack.org
Wiki: https://wiki.openstack.org/wiki/RefStack
Launchpad: https://launchpad.net/refstack
Blueprints: https://blueprints.launchpad.net/refstack
Bugs: https://bugs.launchpad.net/refstack



(Session proposed by Rochelle Grober)


Tuesday May 13, 2014 2:00pm - 2:40pm
B301

2:50pm

Hierarchical Multitenancy in Every Project
A small working group has been planning a strategy for adding Hierarchical Multitenancy to OpenStack. This will require collaboration from all of the projects. General strategy is outlined here:

https://wiki.openstack.org/wiki/HierarchicalMultitenancy

In the session we will explain the proposed plan, collect concerns from stakeholders in all the projects, and identify volunteers to begin work in each project.

(Session proposed by Vishvananda Ishaya)


Tuesday May 13, 2014 2:50pm - 3:30pm
B303

2:50pm

Taking another look at our CLA
Since the earliest days of the OpenStack project, contributors have been required to sign either an Individual or Corporate Contributor License Agreement (ICLA or CCLA) in order to contribute to the project.

There has been one recent, high-profile case where this requirement has prevented a contributor from joining the project. There is also a wider debate gathering momentum in the open-source world about the need for such agreements.

Any change to this policy would require the support of the Foundation board, the legal affairs committee advising the board on IP matters and, ultimately, the Foundation membership in order to approve a change to the Foundation bylaws. However, the project and its current contributors have a role here - we need to build consensus amongst ourselves whether we're happy with the status quo or would like to see some work done around exploring a change to our policy.

Let's take some time to educate ourselves on the purpose of our CLA, talk through the arguments for and against it, share any anecdotes of friction it may have caused, discuss our current implementation of the CLA and whether there is appetite for change amongst within the project.

(Session proposed by Mark McLoughlin)


Tuesday May 13, 2014 2:50pm - 3:30pm
B302

2:50pm

User Experience Designers Gathering
We would like to welcome all User Experience Designers/Developers to join together in a session to discuss a number of things:
-How can you get involved in design for OpenStack?
-How could the current process be improved?
-Discuss the work we've done so far on Personas.
-Discuss the baseline usability testing that we've done.
-How should we collaborate together moving forward?

(Session proposed by Liz Blanchard)


Tuesday May 13, 2014 2:50pm - 3:30pm
B304

2:50pm

Hardware Multitenancy Risk Mitigation
Multi-tenancy using Ironic would be a major feature, but also a scary feature. Let's talk about the risks associated with multi-tenancy, and options for mitigating these risks. We will discuss things such as:

* Poisoned firmware and methods for auditing / blocking it
* Network isolation to keep untrusted hardware off the management network
* Securely erasing storage devices to keep data safe
* Dynamic vs. static node->tenant assignment
* Quotas, hardware flavors, and usage tracking
* Communicating risks, limitations, and best-practices to operators
* Do we need to expose an API to non-privileged users?

Ideal outcome from this session is to identify the risks, agree on how to mitigate those risks, and assign action items.


Etherpad: https://etherpad.openstack.org/p/juno-summit-ironic-multitenancy

(Session proposed by Jim Rollenhagen)


Tuesday May 13, 2014 2:50pm - 3:30pm
B301

2:50pm

Queue Flavors
Marconi's API aims to be as flexible as possible without sacrificing safety, consistency nor availability. Shards introduced the ability to have separate clusters for queues which helps with scaling Marconi horizontally. This process has to be done manually by the system administrator and it's just related to queue's distribution and not specifically to the storage capabilities.

Queue flavors aim to add a way for selecting dynamically which store to use for a specific queue based on the storage capabilities. For instance, it would be possible to create an `in-memory` queue or a `blob` queue, etc.

This would allow the user to have some control over the tradeoffs inherent in the backing store, e.g., do I want a queue that is fast but less durable (e.g., for piping lots of little notification messages - think UDP), or do I want something that is a little slower but offers more guarantees (e.g., for critical metering/billable events - think TCP)?

(Session proposed by Flavio Percoco Premoli)


Tuesday May 13, 2014 2:50pm - 3:30pm
B306

2:50pm

Rally Juno Roadmap
Rally started as a pure benchmark tool for OpenStack project.

During the last 8 months we grow from small script to quite a big testing tool, that allows you to produce clouds, verifies it (using tempest), benchmark it & generate reports.]

It seems like that we could build on this fundament an very interesting for Operators:
1) Verification
2) Health check
3) Track API performance
4) Track VMs performance (cpu/io/mem/network)
5) Periodic tasks
6) Analyze of ceilometer data
7) Integration with horizon + notifications (emails/sms) in case of something went wrong
8) Historical data reports

And other interesting things for cloud operators

More details here:

https://docs.google.com/a/mirantis.com/document/d/1cAgyueiQ__tZ_MG5oOxe4q49tyPQcm-Y1469lmeERq8/edit#


(Session proposed by Boris)


Tuesday May 13, 2014 2:50pm - 3:30pm
B305

3:40pm

Cross-project quota management service endpoint
As more projects come into the OpenStack ecosystem, there continues to be a need to manage and track quotas for the resources these projects provide to users.

A number of problems exist in this space currently:

1) Quota management is done slightly differently within Nova, Neutron and Cinder
2) New projects that expose resources to users must invent their own or copy/paste code from one of the existing quota implementations
3) Quotas are currently tied to a particular cell in Nova, and they need to be managed globally or within a broader-than-cell division

It should be possible to use a driver-based model inside Nova/Cinder/Neutron for quotas, in the same way that volume and network operations are currently modularized (using an API/manager/driver model). One such driver would be the existing DB-based quota drivers, and an external quota driver could be added and worked into Nova's code base -- in the same way that nova-network or nova-volume exist alongside Neutron and Cinder as drivers.

The Boson project [1] aimed at pulling quota management out of Nova and having a separate service endpoint that would handle reservations and quotas for OpenStack services. Seems like it could be a starting place for solving quota management problems.

[1] https://wiki.openstack.org/wiki/Boson

(Session proposed by Jay Pipes)


Tuesday May 13, 2014 3:40pm - 4:20pm
B303

3:40pm

Tracking incoming features
We need to do a better job at tracking features being developed, approve their design, and communicate when they should land. Launchpad blueprints have shown their limits. While StoryBoard holds a lot of promises, it's far from finished yet.

This workshop will discuss various ways of improving this, reflect on recent experiments (trello boards, git repositories...), and brainstorm on future solutions. This will hopefully allow to have a long-term plan to better handle this.

(Session proposed by Thierry Carrez)


Tuesday May 13, 2014 3:40pm - 4:20pm
B302

3:40pm

User Experience Designers Gathering (Part 2)
Part 2 of "User Experience Designers Gathering".

This is an extension of the previous session. This topic was granted 2 time slots.

(Session proposed by Russell Bryant)


Tuesday May 13, 2014 3:40pm - 4:20pm
B304

3:40pm

Planning Ironic's Juno Development
This session will include the following subject(s):

Architectural plans for Ironic in Juno:

Several blueprints and sessions have been put forward, proposing changes to Ironic's API, architecture, or feature capabilities. This session is my attempt to consolidate all of those, outline the various possibilities, and get community input on what is most important -- and achievable -- within Juno. The intent here is not to have a technical discussion about the changes, but get consensus about what to do next, so the project is not pulled in too many directions (which would result in nothing getting done).

Summary of proposed changes can be found here:

https://etherpad.openstack.org/p/juno-summit-ironic-arch

(Session proposed by Devananda)


Tuesday May 13, 2014 3:40pm - 4:20pm
B301

3:40pm

Notifications on Marconi
The project’s goal is to create a service for surfacing events to end users (where a user can be a cloud app developer, or a customer using one of those apps).

For example, a developer may want to be notified when their heat template is finished building, or when one of their servers is low on disk space. Alternatively, a user of MyHipsterApp may want to get a text when one of their friends invites them to listen to That Band You’ve Never Heard Of.

A lot of people have been asking for notifications support. We should come up with a plan to deliver notification features iteratively, so that we can begin delivering value as soon as Juno-1.

See also this pad from a previous brainstorming session with the community: https://etherpad.openstack.org/p/marconi-notifications-brainstorm


(Session proposed by Balaji Iyer)


Tuesday May 13, 2014 3:40pm - 4:20pm
B306

3:40pm

MagnetoDB, key-value storage. OpenStack usecases
MagnetoDB is a key-value storage for OpenStack with seamless scalability by design.

https://wiki.openstack.org/wiki/MagnetoDB
https://launchpad.net/magnetodb

At this session the MagnetoDB project will be presented; architecture and usecases.

We will discuss OpenStack internal use cases and integration with other projects.
- MagnetoDB as storage for OpenStack Celiometer
- MagnetoDB as datasource for Sahara driven Hadoop analytic
- Trove as database provisioning layer for MagnetoDB

(Session proposed by Ilya Sviridov)


Tuesday May 13, 2014 3:40pm - 4:20pm
B305

4:20pm

Break
Tuesday May 13, 2014 4:20pm - 4:40pm
Design Summit area

4:40pm

Barbican plug-in architecture
This session is to refine how the plugin system will work in Barbican. We will be discussing separating the plugin interfaces to reduce overlap as well as where code will reside and how we will ensure that plugins remain up to date and tested.

(Session proposed by Jarret Raim)


Tuesday May 13, 2014 4:40pm - 5:20pm
B301

4:40pm

How do we make it easier to fix the Gate?
Every couple of months we get a giant wedge in the gate which means
that everyone is impacted by giant gate backups. This January we saw a
60hr gate backup happen over the course of a week.

We've been enhancing tools like Elastic Recheck to try to determine
the worst issues we have at any given point. However the fact that we
keep hitting race conditions that wedge everything, and that they take
weeks to get resolved, means we clearly have more to solve.

I'd like to run a conversation in the cross project track to briefly
level set on where we are at, and gather feedback and ideas on what
more could be done to make getting to the bottom of issues more
attractive to core teams. The outputs of this session would be
priorities and work items to make addressing issues found in the gate
faster and easier.


(Session proposed by Sean Dague)


Tuesday May 13, 2014 4:40pm - 5:20pm
B302

4:40pm

How to improve security in your OpenStack project
Come discuss security with the OpenStack Security Group (OSSG) to understand how your project can benefit from the efforts within OSSG. Help OSSG identify gaps in their current efforts and plan the path for the Juno release cycle.

We will begin with some basic details on the current OSSG efforts. And then break into groups to discuss how projects can utilize what OSSG has done, and also how OSSG can better direct their work. Some topics of discussion include:

- Threat modeling / security architecture reviews
- Security design guidelines
- OpenStack Security Guide
- OpenStack Security Notes
- Security testing / automation
- Security impact reviews in gerrit

Come help improve security in OpenStack!

(Session proposed by Bryan D. Payne)


Tuesday May 13, 2014 4:40pm - 5:20pm
B304

4:40pm

OpenStackClient and SDKs and project libraries
There are a number of recent changes to the client library and CLI projects around OpenStack. We will discuss how those relate to OSC, specifically updates to the project libs and the emerging OpenStack SDKs (specifically python-openstacksdk in this case). The focus will be on how OSC relates to and consumes the relevant related projects and not the other projects themselves.

(Session proposed by Dean Troyer)


Tuesday May 13, 2014 4:40pm - 5:20pm
B303

4:40pm

Marconi Dev/Ops Session
Many times we've heard a desire for more feedback and interaction from users. However, their attendance at design summit sessions is met with varied success.

However, last summit, by happy accident, a swift session turned into a something a lot more user driven. A competent user was able to describe their use case, and the developers were able to stage a number of question to them. In this way, some of the assumptions about the way certain things were implemented, and the various priorities of future plans became clearer.

This session proposes to run such an an "ops" session for the Marconi project.

Primarily, the purpose of this session is to for developers to ask the operators to answer questions, and request information. However, operators could also be allowed to tell the developers things (give feedback) as a secondary purpose.


https://etherpad.openstack.org/p/ATL-ops-dedicated-design-summit-sessions
https://etherpad.openstack.org/p/ATL-marconi-ops

(Session proposed by Tom Fifield)


Tuesday May 13, 2014 4:40pm - 5:20pm
B306

4:40pm

Climate, Resource Reservation for OpenStack
It will be nice to discuss future of Climate project, that is currently located on Stackforge. This project aims to bring leasing and resource reservation opportunity to OpenStack, we need to find best solutions and practices for that.

Link to Climate's Launchpad: https://launchpad.net/climate

Related cross-project session: http://summit.openstack.org/cfp/details/45 - here we'll discuss common principles of where that should be placed

(Session proposed by Dina Belova)


Tuesday May 13, 2014 4:40pm - 5:20pm
B305

5:30pm

Barbican SSL/TLS flow
The goal of this session is to discuss the extensions to Barbican required to support asymmetric key types. This work is initially targeted at SSL/TLS certificates, but should account for other asymmetric types like SSH keys. We will be discussing the API changes required as well as any changes to the control flow or data models.

(Session proposed by Jarret Raim)


Tuesday May 13, 2014 5:30pm - 6:10pm
B301

5:30pm

i18n discussion
i18n is enabled in some of the projects and planned to be enabled in the others in Juno. I'd like to propose that we meet to ensure everyone is on the same page with respect to i18n.

In particular:
* What is i18n and why is it valuable.
* What's left to complete support.
-- Possible improvements
* How to best ensure your messages can be translated
-- Supporting right to left locales (e.g. Arabic, Hebrew, etc)

(Session proposed by James Carey)


Tuesday May 13, 2014 5:30pm - 6:10pm
B304

5:30pm

OpenStackClient and SDKs and project libraries (2)
Part 2 of "OpenStackClient and SDKs and project libraries".

This is an extension of the previous session. This topic was granted 2 time slots.

(Session proposed by Russell Bryant)


Tuesday May 13, 2014 5:30pm - 6:10pm
B303

5:30pm

Test Matrices and Feature Parity
The idea for this talk spawned in https://etherpad.openstack.org/p/juno-test-maxtrices. You can refer to the content there, but I have also included the current state of that etherpad here.

During the icehouse cycle we added a few extra features to the check and gate zuul pipelines. In short active changes will be automatically rechecked if their test results become more than 72 hours old and if a change has check results that are more than 24 hours old when approval happens that change will be rechecked prior to queuing in the gate pipeline. The goal behind these changes was to avoid stale test results so that reviewers always have up to data and relevant results.

While these changes have succeeded in keeping results up to date they have traded gate pileups for check pileups. Arguably this was also the intent so not a bad thing, but it would be great if we could further streamline the process for dev and user sanity.

Wouldn't it be great if we could come up with some sort of minimal test matrix that gives us reasonable code coverage? Today we have done this in a fairly ad hoc manner, but a formal matrix with an understanding of the interfaces between different pieces of code should allow us to run fewer tests per change increasing the overall throughput of the system.

Simplified matrix:
TestA TestB TestC TestD
DB MySQL MySQL Postgres Postgres
Hypervisor KVM/QEMU Docker LXC Xen
MQ Rabbit ZMQ Qpid $RANDOM
Cells No Yes No Yes
Networking NovaNet NeutronA NeutronB NuetronC
NeutronA: neutron + linuxbridge
NeutronB: neutron + ovs
NeutronC: neutron + opendaylight
* Note I haven't looked at any code and have no idea if the above remotely makes sense.

So why won't this work? Feature Parity. It turns out we have done a terrible job in maintaining feature parity across the different example rows of that matrix. Nova with cells and Nova without cells support different things. Neutron and nova network don't have feature parity. Same story with the hypervisors. I think the DB layer is just about the only one that *should* work regardless of setup.

We have two intertwined problems here. We run a ton of tests and should be better about what we test which requires us to care about feature parity. We should embrace both problems (and by embrace I mean actually care about them instead of ignoring them). (this is way off in left field and getting into refstack territory >_>) Maybe we should consider chopping off the deadweight from that matrix and focus on testing the things that "work".

I propose that we get everyone in a room and talk about this. We need a better story as an overall project (Openstack) on how we deal with feature parity within and across projects. Assuming we can come up with some concrete ideas around fixing feature parity we should be able to talk about fixing our test matrices too.

(Session proposed by Clark Boylan)


Tuesday May 13, 2014 5:30pm - 6:10pm
B302

5:30pm

Scaling an Individual Queue
I'd like to discuss different scaling strategies and brainstorm around ways we can implement them. Based on the discussion, we can create a blueprint to document the path forward.

--1-- Scale-up by adding the ability to migrate a queue to a higher-performance or lower-densisty storage partition. How would we do this with zero downtime for the user? Should this be manual, automatic, or both? If automatic, should we migrate to consistent hashing for placement?
--2-- Scale-out by adding the ability to shard a single queue across multiple backend storage partitions. The tick with this is continuing to guarantee once-and-only-once delivery in light of the fact that getting things out of order can lead to missing a message when using the feed/listing interface.

(Session proposed by Kurt Griffiths)


Tuesday May 13, 2014 5:30pm - 6:10pm
B306

5:30pm

Discovery and diagnostics for OpenStack
This session is dedicated to projects aimed at operations
of OpenStack-based cloud. Operations is a very broad topic,
including monitoring, discovery and validation of configuration and diagnostic of faults.

Contributors to such projects as StackTach, Rubick, Satori,
Mistral and everyone interested are very welcome.

We would like to discuss main goals:

1. short-term goal of supporting OpenStack gate, including
TripleO deployments with additional automated diagnostics of
faults and cross-services validation of configuration;

2. long-term goal of providing tool set to diagnose clouds
in operation, with configuration discovery and workflow-
based inspections and problem determination in the cloud.

(Session proposed by Oleg Gelbukh)


Tuesday May 13, 2014 5:30pm - 6:10pm
B305
 
Wednesday, May 14
 

9:00am

Ceilometer agents repartition
The ceilometer central agent is responsible for polling a lot of different meters from different OpenStack components. To avoid duplication, this is done by a single central agent, which induces a single point of failure.

At the Icehouse summit, we discussed a plan about to address that. Progress has since been made on an underlying co-ordination protocol facade in the form of tooz[1], but little headway has occurred on addressing this SPoF within ceilometer.

The priority of addressing this architectural defect has been further elevated by the central agent assuming responsibility for hardware polling of nodes over SNMP.

The session will be about how we're going to tackle this definitely in Juno, allowing for the central agent to be scaled out horizontally, with the workload partitioned across the pool of running agents.

Also an unrelated optimization that could possibly be accommodated in the resource discovery layer will be discussed. Specifically we could avoid imposing undue load on nova-api from the compute agent polling, by first calling virt.inspector.inspect_instances() and only hitting nova-api if the hypervisor reports a previously unknown instance (modulo resource-metadata staleness)

[1] https://github.com/stackforge/tooz

(Session proposed by Julien Danjou)


Wednesday May 14, 2014 9:00am - 9:40am
B305

9:00am

Install Guide Discussion Session
Let's talk about the current state of the install guide and how we should work on it for the Juno release:
- baremetal, eventually or in Juno?
- Configuration Files or edit-a-line-at-a-time?
- move nova-network to non-default status?
- review example architectures
- review goals for these install guides
- review audiences for these install guides

(Session proposed by Anne Gentle)


Wednesday May 14, 2014 9:00am - 9:40am
B301

9:00am

Heat dev/ops session
(copied from similar sessions proposed for other projects, possibly there is overlap with the heatclient session related to sysadmin experience http://summit.openstack.org/cfp/details/90, perhaps we can combine the two?)

--
Many times we've heard a desire for more feedback and interaction from users. However, their attendance at design summit sessions is met with varied success.

However, last summit, by happy accident, a swift session turned into a something a lot more user driven. A competent user was able to describe their use case, and the developers were able to stage a number of question to them. In this way, some of the assumptions about the way certain things were implemented, and the various priorities of future plans became clearer.

This session proposes to run such an an "ops" session for the Nova project.

Primarily, the purpose of this session is to for developers to ask the operators to answer questions, and request information. However, operators could also be allowed to tell the developers things (give feedback) as a secondary purpose.


https://etherpad.openstack.org/p/ATL-ops-dedicated-design-summit-sessions

(Session proposed by Steven Hardy)


Wednesday May 14, 2014 9:00am - 9:40am
B302

9:00am

New policies for Neutron in Juno
This session will discuss polices and procedural items for Neutron in Juno:

* The new BP process.
* 3rd party testing requirement redux
* Community contributions vs. vendor plugins/drivers
* OVS and LB deprecation in Juno
* Possible deprecation of metaplugin

(Session proposed by Kyle Mestery)


Wednesday May 14, 2014 9:00am - 9:40am
B304

9:00am

Continuation of third party CI
This session will include the following subject(s):

Continuation of third party CI:

We now hold the hypervisor driver interface to a much higher standard than we used to. Should we hold other plug in interfaces (scheduler, database, etc) to a higher testing standard as well? What would this look like?

(Session proposed by Michael Still)

Raising the bar on virt CI: status and next steps:

Last cycle, we enforced the requirement that all drivers in Nova have functional testing CI systems. Next, we need to work towards meeting a minimum level of performance, in terms of job run time, coverage, and pass percentage.

In this session we should review where we are, and where we need to get to in the Juno cycle.

(Session proposed by Dan Smith)

Base feature requirements for compute drivers:

In the Icehouse cycle, we finished implementing the CI testing requirement for all compute drivers. I feel it's time to visit the next topic around consistency between drivers.

The support matrix for features across the compute drivers is full of gaps. We should decide what base level of functionality is absolutely required for drivers.

- What is the required feature list? How should we decide what's required?

- What timeline should we set for meeting the baseline? What happens if it isn't met?

- How does the resulting list line up with our current set of features marked as the core API for v3?

- Should the requirements change for a container based driver vs. hypervisor?

(Session proposed by Russell Bryant)


Wednesday May 14, 2014 9:00am - 9:40am
B303

9:00am

Release Plan for Low-level Libraries
During Icehouse we prepared tools and did the dependency analysis to release code from the incubator as libraries. During Juno we should work on those releases.

https://wiki.openstack.org/wiki/Oslo/Dependencies
https://wiki.openstack.org/wiki/Oslo/GraduationStatus
https://blueprints.launchpad.net/oslo/juno


(Session proposed by Doug Hellmann)


Wednesday May 14, 2014 9:00am - 9:40am
B306

9:50am

Improve Ceilometer test strategy
This session will include the following subject(s):

Improve Ceilometer test strategy:

Ceilometer has a quite large test base, but it is still not enough or not good enough.

The goal of this session once is to give a brief overview about the issues with testing in Ceilometer, including the missing areas, not well built-up strategy, issues with the testing libraries or even with the test skipping logic. After having a picture about the problems, we can discuss how to improve our test code and what kind of strategies/directions should be followed.

Some highlights from the current experiences:

* The coverage of Ceilometer's code base, based on the lines of code that are covered, has a quite good value (above 85%). But it is still easy to find uncovered branches in every part of the code. Because of the uncovered branches, it is harder to refactor the code or add new functionality, that affects the existing ones, without possibly breaking some working features.

* Another more high-level issue pertains to the potential pitfalls around testing with highly artificial datasets, and potential strategies for exercising the metering pipeline against a more realistic and larger quantum of measurements.

* Finally, we have had ongoing problems with landing substantial coverage in Tempest, largely due to performance issues in the sqlalchemy driver. While continued coverage for this driver is crucial to give deployers with AGPL concerns an alternative to mongodb, we also need a strategy to ensure that mongo itself is adequately tested in the gate (given that certain distros recommend this driver as the only one currently production-ready). The blocker is that Ceilometer depends on features in mongodb 2.4, whereas short of enabling the Ubuntu Cloud Archive, the gate running on Precise is restricted to version 2.0.4. One approach to discuss would be to introduce a mongo-based Tempest variant (in the style of the postgres variant) running on CentOS 7 or Fedora 20. We should also revisit the idea mooted in Portland, to use decorators applied to existing resource-lifecycle testcases to inject additional ceilometer assertions.

Co-proposed with Eoghan Glynn

(Session proposed by Ildiko Vancsa)

New gate jobs for coverage and spelling:

To ensure the acceptable level of code coverage in Ceilometer and also to avoid the periodical misspelling correction patches on review, two new gate jobs were proposed for Ceilometer.

The goal of this session is to identify an efficient way for implementing the proposed gate jobs and also for identifying any additional need regarding to improve the gate jobs for Ceilometer.

Co-proposed with Balazs Gibizer

(Session proposed by Ildiko Vancsa)


Wednesday May 14, 2014 9:50am - 10:30am
B305

9:50am

Next steps for Heat Software Orchestration
With the Icehouse release, Heat includes implementation for software orchestration (Kudos to Steve Baker and Jun Jie Nan) which enables clean separation of any kind of software configuration from compute instances and thus enables a great new set of features. The implementation for software orchestration in Icehouse has probably been the major chunk of work achieve a first end-to-end flow for software configuration thru scripts, Chef or Puppet, but there is more work to be done to fully enable Heat for more software orchestration use cases beyond the current initial support.
This session aims at discussing such additional use cases, and more importantly, discussing design options of how those cases can be addressed. Below is a collection of ideas/suggestions as well as collection of currently known limitations (or points where there have been discussions around optimization).

#1 Enable software components for full lifecycle:
With the current design, "software components" defined thru SoftwareConfig resources allow for only one config (e.g. one script) to be specified. Typically, however, a software component has a lifecycle that is hard to express in a single script. For example, software must be installed (created), there should be support for suspend/resume handling, and it should be possible to allow for deletion-logic. This is also in line with the general Heat resource lifecycle.
By means of the optional 'actions' property of SoftwareConfig it is possible to specify at which lifecycle action of a SoftwareDeployment resource the single config hook shall be executed at runtime. However, for modeling complete handling of a software component, this would require a number of separate SoftwareConfig and SoftwareDeployment resources to be defined which makes a template more verbose than it would have to be.
As an optimization, SoftwareConfig should allow for providing several hooks to address all default lifecycle operations that would then be triggered thru the respective lifecycle actions of a SoftwareDeployment resource. Resulting SoftwareConfig definitions could then look like the one outlined below. This will also enable a closer alignment and straight-forward mapping to the TOSCA Simple Profile YAML work done at OASIS and the heat-translator StackForge project.

my_sw_config:
type: OS::Heat::SoftwareConfig
properties:
create_config: # the hook for software install
suspend_config: # hook for suspend action
resume_config: # hook for resume action
delete_config: # hook for delete action

#2 Enable add-hoc actions on software components:
Apart from basic resource lifecycle hooks, it would be desirable to allow for invocation of add-hoc actions on software. Examples would be the ad-hoc creation of DB backups, application of patches, or creation of users for an application. Such hooks (implemented as scripts, Chef recipes or Puppet facts) could be defined in the same way as basic lifecycle hooks. They could be triggered by doing property updates on the respective SoftwareDeployment resources (just a thought and to be discussed during design sessions).

#3 address known limitations of Heat software orchestration
As of today, there already are a couple of know limitations or points where we have seen the need for additional discussion and design work. Below is a collection of such issues:

#3.1 software deployment should run just once:
A bug has been raised because with today's implementation it can happen that SoftwareDeployments get executed multiple times. There has been some discussion around this issue but no final conclusion. An average user will however assume that his automation gets run only or exactly once. When using existing scripts, it would be an additional burden to require rewrites to cope with multiple invocations. Therefore, we should have a generic solution to the problem so that users do not have to deal with this complex problem.

#3.2 dependency on heat-cfn-api:
Some parts of current signaling still depend on the heat-cfn-api. While work seems underway to completely move to Heat native signaling, some cleanup to make sure this is used throughout the code.

#3.3 connectivity of instances to heat engine API:
The current metadata and signaling framework has certain dependencies on connectivity from VMs to the Heat engine API. With some network setups, and in some customer environments we hit limitations of access from VMs to the management server. What can be done to enable additional network setups?

#3.4 number of created keystone users for deployments:
It has been pointed out that a large number of keystone users get created for deployment and concerns have been raised that this could be a problem for large deployments.

#3.5 support of server groups:
How can a clean model look like where software configs get deployed on server groups instead of single servers. What is the recommended modeling and semantics?

#3.6 handling of stack updates for software config:
Stack updates are not cleanly supported with the initial software orchestration implementation. #1 above could address this issue, but do we have to do something in addition?

#3.7 stack-abandon and stack-adopt for software-config:
Issues have been found for stack-abandon and stack-adopt with software configs that need to be addressed. Can this be handled by additional hooks as lined out under #1?


(Session proposed by Thoms Spatzier)


Wednesday May 14, 2014 9:50am - 10:30am
B302

9:50am

Elastic Recheck next steps
Over the course of Icehouse Elastic Recheck grew up quite a bit. We're
now regularly tracking 70+ race bugs. We've got some analytics for
both overall hits and gate specific hits. We've got the uncategorized
hit list which helps us figure out what's next. And we've got a nice
active review team keeping query quality way up.

However there is still plenty to do. Retiring the rechecks
page. Normalizing the data. Duplicate detection. This session will
give a brief overview of where we came, what is currently working well
and what isn't, and build out the work going forward, with priorities
and hopefully owners on items


(Session proposed by Sean Dague)


Wednesday May 14, 2014 9:50am - 10:30am
B301

9:50am

Code Review Process Improvements
This session will include the following subject(s):

Code Review Process Improvements:

Neutron, like many OpenStack projects, is having trouble ensuring the quality and timeliness of patch review. While more core reviewers are clearly needed, there is also room for improving the effectiveness of the review process. This session is intended to facilitate discussion about possible solutions to common issues.

A short list of problems could include:

* patch velocity (how long it takes for a patch to merge from time of initial submission)
* reviewer engagement (knowing enough about patch intent and how it fits with existing code)
* determining which patches are most in need of reviewer attention can be unnecessary complex
* new patches can languish unreviewed for extended periods
* keeping abreast of review status is harder due to testing comments

(Session proposed by Maru Newby)


Wednesday May 14, 2014 9:50am - 10:30am
B304

9:50am

Clustered hypervisor support in Nova
There are now a few clustered/remote hypervisors being maintained for Nova which do not fit the predominant distribution model of: many nova-compute agents, each managing a fixed pool of discrete local resources.

Ironic, HyperV, and VMWare all face similar challenges in this area.

For example, with Ironic [*], there should not be any dependency on which nova-compute host any given task is sent to, as it will simply be relayed to Ironic's API and from there to the appropriate ironic-conductor host. Having multiple nova-compute hosts today can only be done if each service's "host" name is the same, or else the scheduler will get confused by seeing multiple copies of all resources. Even with this shoddy hack, there are doubtless considerable race conditions if the scheduler were to claim the same ironic node and request different compute hosts to provision it simultaneously (which is partly worked around by the retry filter and a lock in Ironic).

One proposal to address this for remote hypervisors, discussed back in Portland, was to allow the nova-conductor process to talk directly to said hypervisors, instead of going through nova-compute.

Another proposal was to change the way resources are identified within the ComputeManager and ResourceManager to be merely (hypervisor_hostname) rather than (host, hypervisor_hostname).

There are probably other solutions, too.

Let's discuss.


[*]
Short term solution for Ironic:
https://review.openstack.org/#q,I68d46c4da,n,z

(Session proposed by Devananda)


Wednesday May 14, 2014 9:50am - 10:30am
B303

9:50am

oslo.messaging status and plans for Juno
oslo.messaging is a library for doing RPC and notifications over various supported messaging technologies.

Let's discuss the current status of oslo.messaging adoption, removing openstack.common.rpc in Juno and blueprints proposed for Juno like trusted messaging, asyncio/trollius executor, proton/amqp-1.0 driver, unix socket driver, messaging proxy, etc.

Blueprints: oslo.messaging/trusted-messaging oslo.messaging/asyncio-executor oslo.messaging/amqp10-driver-implementation oslo.messaging/message-proxy-server

(Session proposed by Mark McLoughlin)


Wednesday May 14, 2014 9:50am - 10:30am
B306

10:30am

Break
Wednesday May 14, 2014 10:30am - 11:00am
Design Summit area

10:35am

Keysigning
In an effort to build a secure web of trust, some community members will perform an informal exchange of identification and confirm key fingerprints at the OpenStack Juno Design Summit on Wednesday the 14th of May starting at 10:35 AM EDT (14:35 UTC) in room B301 of the Georgia World Congress Center (in between Infrastructure topic sessions). See details at https://wiki.openstack.org/wiki/OpenPGP_Web_of_Trust/Juno_Summit

Wednesday May 14, 2014 10:35am - 11:00am
B301

11:00am

Complex query on Ceilometer stats & project-specific meters
This session will include the following subject(s):

Complex query support for statistics:

The rich query functionality, implemented by the Complex filter expressions in API queries blueprint, is available for Samples, Alarms and Alarm History, however this functionality is applicable for Statistics as well. The current implementation supports selectable parametrized aggregate functions (e.g. cardinality) with at most a single parameter per function. The idea is to provide the possibility of using the complex query functionality for Statistics and use the flexibility of the JSON representation of the request body for supporting the definition of multiple parameters for a selectable aggregate. This extension will also support all the functions that are available via the /meters endpoint with simple query.

The goal of this session is to discuss the API design and the supported features in a statistics request.

(Session proposed by Ildiko Vancsa)

Project-based data collection configuration:

Ceilometer now supports only a global configuration for pipelines, which means that the parameters set for meters are applicable for all projects/tenants. There would be several advantages of provide the possibility to configure the data collection mechanism for projects/tenants, like storing as much data as necessary and also to make Ceilometer more flexible related to the customer needs.

Currently only the virtual resources are aware of the corresponding project, therefore this configuration improvement will be implemented first for the meters of virtual resources. The next step would be to extend the functionality also to the physical/project-less resources.

(Session proposed by Ildiko Vancsa)


Wednesday May 14, 2014 11:00am - 11:40am
B305

11:00am

Heat Scaling, Robustness and Convergence
This session will include the following subject(s):

scaling & robustness for heat:

Lets make heat more robust and scalable when dealing with real world clouds.

TripleO has spent a year working with Heat and learning about common failure modes and glitches that make production use by non-experts hard (at best) and impossible at worst.

The issues we've encountered:
- scaling of single large stacks (e.g. I have a 10K node cluster, why is that constrained to run in a single heat engine)
- dealing with the real world: backend APIs can and do fail - in myriad ways - manual intervention to fix these is pointless - given a desired cluster definition, it is heats job to keep pushing to converge on that state
- fast, graceful failover [e.g. look more like something like galera to clients] of failed heat engines - a failed heat engine is a fact of life in production environments (e.g. due to deployments) and having that cause user visible issues is a significant confidence issue).
- stacks mid update cannot have their templates/parameters updated until it completes.
- heat doesn't notice that resources have failed or stopped behaving correctly

Clint and I will give a quick walk through a possible underlying architecture to address scale and robustness from the ground up, and then the rest of the session can be a mix of poking holes in that approach / coming up with alternative designs.

(Session proposed by Robert Collins)


Wednesday May 14, 2014 11:00am - 11:40am
B302

11:00am

Jenkins moving forward
We have reached the limit of Jenkins before with the need to continually grow our master Jenkins nodes. With zuul, gearman, nodepool and all the other work that infra has taken on to improve CI is it time to visit replacing Jenkins with an alternative?

I'd like to discuss the critical path towards replacing Jenkins. Specifically what features are required by a potential test runner (such as turbo-hipster) to fulfill infra's needs. For example, should we be looking at providing feature-parity with existing JJB files (ie workers able to interpret job requirements from JJB) or should we take this opportunity to redefine jobs into a subset of Jenkins modules/features?

An implementation strategy should also be thought of. For example, do we have the resources to run every job twice to compare Jenkins' results to another system? If not, how many jobs should we compare (10% etc?). Or maybe we just compare in an experimental pipeline. Regardless I think for a while we will have an overlap where we need to run Jenkins for more complicated to port jobs.

(Session proposed by Joshua Hesketh)


Wednesday May 14, 2014 11:00am - 11:40am
B301

11:00am

IPv6 status in Neutron
Discuss the current status of development, and the future of IPv6 in Neutron.

(Session proposed by Sean M. Collins)


Wednesday May 14, 2014 11:00am - 11:40am
B304

11:00am

The road to deprecating nova.virt.baremetal
I would like to discuss the road ahead for the nova.virt.ironic driver and formulate a plan that we can all agree on to deprecating the nova.virt.baremetal driver at the end of Juno. I hope we can find a solution which makes this process pain-free for both Nova's and Ironic's developer community.

Current state, as of April 2nd, that bears calling out:
* the nova.virt.ironic driver currently lives in the openstack/ironic project.
* configuring nova with "compute_driver=ironic.nova.virt.ironic.IronicDriver" works. (and it's in devstack)
* functional and integration testing of ironic, including using tempest with this driver, is nearly complete. Let's assume it will be done by the Summit.
* Ironic is going to gate on these tests ASAP.
* Nova is *not* going to gate on these tests in Juno, because integrated projects can't gate on incubated projects.
* Ironic will be added to the global gate when it graduates (presumably at the start of "K").

So...

When does it make sense for us to propose the nova.virt.ironic driver to Nova?

Moving the driver into Nova's tree, while Ironic gates on it but Nova does not, seems destined to cause significant pain for developers.

Regardless of which tree the nova.virt.ironic code is in, how do we manage asymmetric gating during Juno, while Ironic depends on an internal API that Nova can change at any time?

Lastly, will Nova ever accept a non-libvirt driver into it's gate, even if it's an integrated OpenStack project and the testing is done upstream?

(Session proposed by Devananda)


Wednesday May 14, 2014 11:00am - 11:40am
B303

11:00am

AMQP 1.0 protocol driver
This session would provide an overview of the AMQP 1.0 oslo.messaging driver that has been under development for the last couple of months.

The goal would be to overview the driver implementation, its capabilities, and the addressing model that it uses.


The submission form won't accept the blueprint name, so here's a link:

https://blueprints.launchpad.net/oslo.messaging/+spec/amqp10-driver-implementation


(Session proposed by Ken Giusti)


Wednesday May 14, 2014 11:00am - 11:40am
B306

11:50am

Rethinking Ceilometer as Time-Series-Data-as-a-Service
This session will include the following subject(s):

Time-Series-Data-as-a-Service:

We will discuss the benefits and potential pitfalls of ceilometer switching to a much more lightweight form of metric store optimized for time series data, without carrying the weight of highly repetitive free-form metadata.

(Session proposed by Eoghan Glynn)


Wednesday May 14, 2014 11:50am - 12:30pm
B305

11:50am

Augmenting polling with notifications
This session will include the following subject(s):

Using notifications:

Instead of polling backend APIs to get an updated status of a resource, Heat should subscribe to notifications when they exist, and simply wait for the relevant information to show up.

We could start by moving the nova server creation.

Topics to discuss:
* Implementation strategy: Do we have a separate process subscribing to the broker? Do we subscribe to all the messages and filter afterwards?
* Do we keep the current polling system as a backward compatible mechanism?
* Race conditions
* Timeouts

(Session proposed by Thomas Herve)


Wednesday May 14, 2014 11:50am - 12:30pm
B302

11:50am

Improving Third Party Testing
Prior to the Icehouse cycle there were only a couple third party test accounts. During the Icehouse cycle we added many more. What have we learned about using third party tests and how can we make that information more valuable for openstack?

I don't want this session to be a how to run a third party infrastructure. In fact I don't think we should spend much time if any at all on the third party side of the equation. Instead Openstack should be looking at what it can do to help third party testers and in turn the test results and projects they test.

Things to cover:
* Requirements for third party testers (logs, timestamps, minimal level of testing, etc)
* Should openstack prescribe a testing infrastructure?
* Account management. Can we make this self service?
* Criteria for gaining voting privs, losing voting privs (different rules for stackforge?)
* Most importantly, how can we better present the data to individual projects. I think there is some sense that the Gerrit comment system may not scale to 5 or more CI systems all interacting with a change. Feedback on what reviewers want to see, information they need would be great.

(Session proposed by Clark Boylan)


Wednesday May 14, 2014 11:50am - 12:30pm
B301

11:50am

Hierarchical Multitenancy
https://etherpad.openstack.org/p/juno-keystone-hierarchical-multitenancy

This session will include the following subject(s):

VPC Modeling:

One of the key capabilities lacking in OpenStack is a formal way to model multi-tenancy. Recently our team from eBay Inc brought up the question of VPCs - see https://wiki.openstack.org/wiki/Blueprint-VPC and https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg16574.html for the discussion.

Given that tenancy and discovery start with Keystone, I propose to discuss the possibilities starting with Keystone.

(Session proposed by Subbu Allamaraju)

Support for Virtual Organisations:

A VO is a collaboration of users from different organisations who work together on a particular project. With federated Keystone, we need to be able to identify subsests of users from different IdPs who are members of the same VO, and who should have related access rights to the VO's resources in OpenStack.
This session will discuss the different ways that we might use to achieve the easy management of VOs, and the additional tools and APIs that will be needed to Keystone for this.

(Session proposed by David Chadwick)

Support for Hierarchical administrative boundary:

Keystone should support domain hierarchy to establish Hierarchical administrative boundary. This is needed to support Reseller or "virtual cloud on a physical cloud", as example given below

Example:

Service provider (GlobalSvcInc) sells its services to multiple customers over 3rd party cloud establishments (CloudProviderInc). GlobalSvcInc wanted to have virtual cloud on CloudProviderInc's cloud infrastructure.

(Session proposed by atiwari)

Hierarchical Projects in Keystone:

Our prototype implements the concept of hierarchical projects using Keystone V3 concepts. The idea of hierarchical projects originateed with Vish proposal of Hierarchical Multitenancy and our prototype shows how this can be achieved without it being disruptive to our community.
This is achieved by maintaining a domain as a container of the hierarchical projects tree, this way it is not necessary to remove the domain concept and the hierarchy maintain compatibility with nova. It works with the current Keystone V3 concepts and may work well with Keystone Federation.

(Session proposed by Telles Mota Vidal Nóbrega)


Wednesday May 14, 2014 11:50am - 12:30pm
B306

11:50am

ML2 Juno Roadmap
Internal ML2 technical details and architecture session.

This session will include the following subject(s):

Extension support for ML2 Mechanism Drivers:

Support for extensions in ML2 Mechanism Drivers.

Blueprint:
https://blueprints.launchpad.net/neutron/+spec/neutron-ml2-mechanismdriver-extensions

With existing ML2Plugin, only extensions defined in the plugin are supported and if a mechanism driver defines
a new extension it won't be loaded.
This blueprint is addressing this issue.

The following changes can be considered as a solution to support extensions in mechanism driver:
1. If mechanism driver needs to support any extension, it should add:
a) _supported_extension_aliases attribute to its class.
b) extension path to the api_extensions_path.
2. Add new method in Ml2Plugin:
This new method should go through the order_mech_drivers and if there is any aliases supported, add it to existing
list of aliases in the Ml2Plugin (i.e. _supported_extension_aliases)

3. In resource's post/pre_commit method (for network, port, subnet) there is no way for mechanism driver to know the original
data passed to the plaugin.
For instance for network resource, when a network is created with an extension attribute in the network parameters, according
to the code below, the 'result' and 'mech_context' do not include the extension's attribute. So mechanism driver cannot use
the required info passed to the create_network.
365 def create_network(self, context, network):
366 net_data = network['network']

Wednesday May 14, 2014 11:50am - 12:30pm
B304

11:50am

Data transfer service plug-in
This session will include the following subject(s):

Data transfer service plug-in:

Nova has implemented the native functions for some hypervisors to do live
migration, e.g. libvirt, VMware VCenter, etc. Shared storage(NFS) and
block(iSCSI) migration have been implemented as well. To meet the need of
migrating data(like VMs) between the machines within one network as the
first use cases mentioned above, this is fairly enough. To transfer huge data
from one machine to another in a different network or outside the firewall, in
which case we are unable to establish the NFS or iSCSI connection, other
transfer protocols, like FTP, need to be taken into account.
This proposal will abstract a data transfer plug-in for the transfer protocols
to implement. Any protocols, like NFS, iSCSI, ftp, bitTorrent, etc, can be put
in this module for nova to use. BitTorrent,
Furthermore, FTP will be taken to transfer data between two machines in
different networks fill up the second use case. BitTorrent, which has been
implemented for image download in Xen, can be implemented as well for
transferring the same data among many machines simultaneously.

Patch for nova-specs: https://review.openstack.org/#/c/87207/

(Session proposed by houshengbo)

Image Upload Plug-in:

Since nova has supported direct downloads from glance locations, another way round direct uploads can make uploading image/snapshot from nova to glance more efficient. It also provides more opportunities for other protocols to implement, e.g. ftp, etc. This blueprint is opposite to https://review.openstack.org/#/c/37817/.

Patch for nova-specs: https://review.openstack.org/#/c/84671/

(Session proposed by houshengbo)


Wednesday May 14, 2014 11:50am - 12:30pm
B303

12:30pm

Lunch
Wednesday May 14, 2014 12:30pm - 1:50pm
Expo Hall, Level 1

1:50pm

Revise data model to improve performance
Currently ceilometer data model is not able to provide good performance at high scale. I think that we should discuss possible changes needed in data model needed to achieve better performance.

To achieve this we need:
* analyze existing bottlenecks
* analyze end-user use-cases (to find rarely used cases or to cover cases that are highly demanded)
* discuss improvements in model that can be done to achieve better performance and coverage of use-cases

New model may also require releasing a new version of the API.

(Session proposed by Alexei Kornienko)


Wednesday May 14, 2014 1:50pm - 2:30pm
B305

1:50pm

Event notifications
This session will include the following subject(s):

Events Refactoring:

We've discussed issues with the events table in the past and the possible headaches that entails. I propose we discuss refactoring all of our eventing to use notifications and multiple simultanious backends.

* use notifications for all eventing
* develop a default notifier that sends events to events table, but allow for no events stored in the db
* allow the user to configure several notifiers (if oslo.notification doesn't already support it)
* allow user to specify a Marconi queue per stack to receive notification events as well
* What do we do about the events endpoints (?)

(Session proposed by Randall Burt)


Wednesday May 14, 2014 1:50pm - 2:30pm
B302

1:50pm

Keystone DevOps
https://etherpad.openstack.org/p/juno-keystone-devops

This session will include the following subject(s):

Running Keystone in different environments:

OpenStack operators may want to run Keystone in a variety of environments that best fit their operational needs and existing identity infrastructure. Examples include the following:

* Targeting PyPy for performance.
* Using Jython or IronPython for working with Java-based or .Net-based infrastructure.

We can motivate this discussion by considering the scenario of using Keystone on Jython to work with an existing Java-based identity environment. There are a number of reasons why this could be a good option:

* Operators may be running an existing identity infrastructure to support legacy usage in their data center(s). They would prefer to provide a seamless experience to their customers as they migrate to completely using OpenStack.

* Porting existing Java code to Python is avoided. This is especially helpful when considering that such operators want to avoid additional and significant investment in legacy approaches, but instead want to move such code to maintenance mode. Java APIs can instead be directly used by a Keystone driver, which helps improve the performance picture as well.

* In the side-by-side migration, both Keystone and legacy services can be deployed in the same servlet container, given that WSGI can be readily mapped to the servlet API. This simplifies deployment during the transition, avoids additional latency overhead, and does not require wrapping existing Java code in REST APIs that can then be consumed. This is especially important if there is any impedance mismatch between the identity models that could result in additional overhead.

* Other possibilities include being able to access a wealth of Java based APIs (Shibboleth and others).

Note that Keystone is well-suited for considering these types of deployment questions. Keystone does not use eventlets/greenlets, making it much more portable to alternatives like Jython or IronPython. In addition, seamless identity support is generally expected by customers, compared to perhaps other APIs operators would need to support.

(Session proposed by Jim Baker)

Keystone Dev/Ops Session:

Many times we've heard a desire for more feedback and interaction from users. However, their attendance at design summit sessions is met with varied success.

However, last summit, by happy accident, a swift session turned into a something a lot more user driven. A competent user was able to describe their use case, and the developers were able to stage a number of question to them. In this way, some of the assumptions about the way certain things were implemented, and the various priorities of future plans became clearer.

This session proposes to run such an an "ops" session for the Keystone project.

Primarily, the purpose of this session is to for developers to ask the operators to answer questions, and request information. However, operators could also be allowed to tell the developers things (give feedback) as a secondary purpose.


https://etherpad.openstack.org/p/ATL-ops-dedicated-design-summit-sessions

(Session proposed by Tom Fifield)


Wednesday May 14, 2014 1:50pm - 2:30pm
B306

1:50pm

Refactoring the Neutron Server Core
In this session, we will examine a proposal to refactor the Neutron server core. The end result of the refactor will make testing, plugin/driver development, and REST dispatching easier. We will cover the multi-cycle plan and dive into the immediate changes for Juno.

(Session proposed by Mark McClain)


Wednesday May 14, 2014 1:50pm - 2:30pm
B304

1:50pm

Next steps in live upgrade
Icehouse was the first release to have some amount of live-upgrade-ability from the previous release. We need to extend that to cover more scenarios (i.e those where computes may need to coordinate), expand our testing of the upgrade scenario, and also address other topics such as DB migrations that don't require downtime or significantly degrade performance.

(Session proposed by Dan Smith)


Wednesday May 14, 2014 1:50pm - 2:30pm
B303

1:50pm

Release branches, QA and requirements
The release process is based on branch juggling from master to milestone-proposed to stable/X. This has interesting consequences on QA, creating a window just before release where (a) you can introduce tempest changes that would break release branches and (b) you can't really have grenade jobs on the development branch. This session will discuss a way out of this maze.

In the remaining time, we'll discuss improvements to the process around global requirements (and the openstack/requirements repository).

(Session proposed by Thierry Carrez)


Wednesday May 14, 2014 1:50pm - 2:30pm
B301

2:40pm

Ceilometer Dev/Ops Session

Many times we've heard a desire for more feedback and interaction from users. However, their attendance at design summit sessions is met with varied success.

However, last summit, by happy accident, a swift session turned into a something a lot more user driven. A competent user was able to describe their use case, and the developers were able to stage a number of question to them. In this way, some of the assumptions about the way certain things were implemented, and the various priorities of future plans became clearer.

This session proposes to run such an an "ops" session for the Ceilometer project.

Primarily, the purpose of this session is to for developers to ask the operators to answer questions, and request information. However, operators could also be allowed to tell the developers things (give feedback) as a secondary purpose.


https://etherpad.openstack.org/p/ATL-ops-dedicated-design-summit-sessions

(Session proposed by Tom Fifield)


Wednesday May 14, 2014 2:40pm - 3:20pm
B305

2:40pm

Stack and Resource lifecycle callbacks
It has been requested that the user deploying the stack receive a callback notification during the lifecycle of a stack in order to insert custom steps/validation/whatever into the existing orchestration. This session is to discuss and finalize the design of such a feature and to get commitment for delivery in Juno.

Basically, the user would add template elements to define at both a stack and resource level, callback urls that Heat would call prior to the particular lifecycle event. The user would also be able to define response codes that Heat would use to determine if the stack could continue or should be marked as failed.

We could also allow the user to define their own payload using str_replace and other intrinsic functions. Authentication needs discussing.

We can determine the actual events but a rough guess:

Stack:
PRE/POST CREATE/UPDATE/DELETE
Resource:
PRE/POST CREATE/UPDATE/DELETE
PRE/POST CHECK (CREATE/DELETE/UPDATE)

(Session proposed by Randall Burt)


Wednesday May 14, 2014 2:40pm - 3:20pm
B302

2:40pm

python-keystoneclient
https://etherpad.openstack.org/p/juno-keystone-client

This session will include the following subject(s):

Keystoneclient discussions:

The session for all things related to interacting with keystone.

Specific points:

- V3 everywhere: Within the Juno cycle v3 keystone should be the default. What's still required and how do we go about making the transition.
If you are involved in another python-*client, what do you need to do. Please bring along any of your own experiences.

- Extension handling from the client side: Loading managers with stevedore is becoming popular - do we want to go down this route client side? Are we committing to HATEOAS or should we be listing extensions on the server? Can we see some unity between client side and server side here.

- Auth plugins for federation and discoverability: We no longer just authenticate against /auth/tokens. Now we can have different endpoints with different apache supported mechanisms. As a user how do i find this and what do we expect clients to provide to make this work?

- Token/Endpoint binding: Your endpoints are listed in your tokens but there is no enforcement that your token can only be used with these endpoints. How can we enforce this - or should we even try?

(Session proposed by Jamie Lennox)


Wednesday May 14, 2014 2:40pm - 3:20pm
B306

2:40pm

Nova-Net to Neutron migration
As part of neutron-nova parity effort it was decided to implement a Nova-network to Neutrom migration.
This migration will allow an administrator to switch network manager of a running virtual machine instance
from Nova-network's one to Neutron.

Current plan:
Juno-1: Flat Nova to Flat Neutron Migration
Juno-2: VlanManager to Neutron
Juno-3: Multi-host migration

Things to be discussed:

1. Key points
- Control plane outage will be necessary:
- Needed to ensure resources are properly transitioned from Nova to Neutron
- Instances should stay running and not need restarting.
- Brief data plane outage is possible as some L3 services are transferred:
- Routing
- DHCP

2. Migration process
- Nova API extension similar to instance live-migration?

3. Migration components
Nova side - ?
Neutron side - ?

4. Possible restrictions?
Nova side -
Neutron side -

https://etherpad.openstack.org/p/novanet-neutron-migration

(Session proposed by Oleg Bondarev)


Wednesday May 14, 2014 2:40pm - 3:20pm
B304

2:40pm

Image precaching service
The current image download mechanism has the following potential issues:
- The first build of a server can be very slow with long image download times.
- Building many servers at once can potentially throttle the network with many image
downloads.

In this session we will discuss introducing a new nova service to pre-cache high priority images on compute hosts prior to the image being requested during the normal instance creation process.

Nova-spec: https://review.openstack.org/#/c/85768/


(Session proposed by Brian Elliott)


Wednesday May 14, 2014 2:40pm - 3:20pm
B303

2:40pm

Branchless Tempest
At the end of the Icehouse cycle we decided that branches in Tempest
were actually inhibiting the project goals of being a test suite that
works equally well in any OpenStack environment. Too many assumptions
were being made about running with the same branch of OpenStack. While
this works fine for the gate, and for Linux distros, it actually maps
very poorly to public clouds, or any CDing environment. So there is no
stable/icehouse Tempest branch, and will not be another new stable
branch in the future.

This discussion will include some time to explain why we did this, and
the major implications. It will primarily be about the remaining steps
to handle all situations with branchless Tempest. Topics we expect to
cover:

* Remaining devstack-gate work to do extension selection per branch
* Tempest releases (we should still probably do releases for end user
convenience, what kind of timecycle should those be on?)
* How and when to deprecate / remove code from Tempest now that it
must run on multiple upstream branches
* What kinds of feature flags we believe we should have
* Configuration compatibility guaruntees (now that we're going to
have a bunch of options that deployers need to set).


(Session proposed by Sean Dague)


Wednesday May 14, 2014 2:40pm - 3:20pm
B301

3:30pm

Ceilometer SNMP improvements & code-free meters
This session will include the following subject(s):

improve snmp inspector and h/w pollster :

Just like Eoghan Glynn pointed out, there are some improvements we can do about the snmp inspector and potentially the h/w pollster we added in the Icehouse release:

1. It would be nice to have a generic mapping mechanism between the snmp OID and final sample in snmp inspector. The goal would be that new OID-sample mappings could be added to the mix *without* writing any new code(or writing as little code as possible)

2. How to manage the snmp credential

3. Misc
- Support bulkCmd mode in snmp
- Is the inspector data definition too snmp-ish?


(Session proposed by Lianhao Lu)

Avoid writing code while introducing new meters:

Each time a new meter is introduced in Ceilometer, we need to perform a lot of tasks like:
1) Adding a mapping in setup.cfg for the new meter to a Pollster
2) Writing a pollster for the counter
3) Implementing the corresponding method in inspectors to collect data for the meter.

Hypervisors like Vsphere come with a single generic API for querying statistics for any meter. Moreover, it supports over 300 such meters. From the development perspective, it will be very difficult, time-consuming and unnecessary to implement a pollster for each and every such meter.

From a customer perspective too, the following difficulties exist:
1) Though Vsphere supports 300+ meters, all the data is not available via Ceilometer.
2) There is no way for the customers to be able to select the meters for which data should be collected by Ceilometer.
3) Even if the developers put in the efforts to collect data for each and every Vsphere meter, if the customer is interested only in some specific meters, it will be an unnecessary load on Ceilometer to collect data for so many meters.

Hence, we propose to implement a generic solution where:

A configuration file can be provided in Ceilometer, which will have a mapping of Ceilometer's meter to the corresponding Vsphere's (or any such other hypervisor's) counter. Customers can directly add/remove these mappings, so that they can have control over which meters to populate in Ceilometer. The configuration file can have additional parameters like, conversion factor for the meters and/or method in the corresponding inspector to be used to populate the meter, if the methods are not generic enough.

We can publish sample configuration files for all the meters, and for each hypervisor.

(Session proposed by Piyush Masrani)


Wednesday May 14, 2014 3:30pm - 4:10pm
B305

3:30pm

Heat API v2
We'll also discuss potential improvements to the Heat client that could make things easier for sysadmins.

This session will include the following subject(s):

V2 API:

Session to discuss/finalize the blueprints/requirements needed to start work on the Heat v2 Rest API during Juno.

(Session proposed by Randall Burt)


Wednesday May 14, 2014 3:30pm - 4:10pm
B302

3:30pm

Handling of static files
This session will include the following subject(s):

Handling of static files:

We have a number of problems related to static files in Horizon right now, and we have to come up with a solution that solves them. The problems include:

* bundling of JavaScript libraries,
* testing and minification of JavaScript code,
* compiling of the style files,
* structure and hierarchy of the style files,
* pluggability of the style files.

This is also closely related to the splitting of Horizon into two parts -- without changing how we handle style files, this split would be problematic.

(Session proposed by Radomir Dopieralski)

Separation of Horizon and Dashboard - II:

Last summit, we all agreed on putting Horizon as
framework and OpenStack Dashboard into two separate
repositories. Not much has happened since then.

An issue is, in Horizon are several (outdated) JavaScript
libraries bundled, they should be moved out of the code, and should
be replaced by some pip compatible component, like django-xstatic and
xstatic-* packages like xstatic-jquery or directly by using django-jquery.

The goal of this session will be, to select providers for javascript libraries and to coordinate the people, who offered help here.

(Session proposed by Matthias Runge)


Wednesday May 14, 2014 3:30pm - 4:10pm
B306

3:30pm

Integrating Tasks into Neutron
In many instances the Neutron API provides confusing semantics on whether an action is synchronous or asynchronous. As a result, many of the plugins and drivers must implement special handling to make the API, database transaction state, and backend state remain coherent. In this session, we will discuss how we move many common actions into asynchronous tasks to improve concurrency, reduce duplicative code and make it easier for robust plugins/drivers to be implemented.

(Session proposed by Mark McClain)


Wednesday May 14, 2014 3:30pm - 4:10pm
B304

3:30pm

Flavor storage re-vamp
Right now, nova is storing flavor information in system_metadata (current details about Instance, potentially former details for resize rollback, and potentially new details for resizes in progress). I don't believe any extra_specs information is stored.

Using system_metadata for this is a bit fragile, doesn't allow us to do any indexing, and makes it difficult to add new features related to flavors.

(Some new features I'd like to see involve a concept of Flavor Groups, where you can assign flavors to group names. Quotas per flavor group, cells/aggregates naming supported flavor groups, and policies based on flavor groups are some ext.. and then apply policies based on the groups.)

We've planned to remove instance_type_id from Instance and strictly rely on system_metadata, but I think this may not be the right way to go. We do need to remove instance_type_id, but I'm thinking we may want a new table to store mappings of Instance -> Flavor information.

The purpose of this session is to come up with ideas on how we should store flavor information tied to instances, accounting for some future uses of flavors.









(Session proposed by Chris Behrens)


Wednesday May 14, 2014 3:30pm - 4:10pm
B303

3:30pm

Tempest documentation gaps
There has been a tremendous growth in the number of contributors to tempest in the past couple of cycles. With >150 people contributing to tempest during Icehouse compared to just a year ago during the Grizzly cycle when there were only ~60 contributors. This coupled with the growing development velocity in the project, has meant that the poor state of tempest documentation leaves both new developers and tempest users lost. Most of the knowledge around using tempest is in the heads of a few developers which isn't published anywhere.

This session will be a discussion of what documentation gaps we have in tempest. Specifically discussing things like which areas need to be fleshed out more, where we need to push documentation, (whether it be the generated sphinx docs, wiki pages, etc) and things like writing a tempest users/operations guide which we don't have today.

(Session proposed by Matthew Treinish)


Wednesday May 14, 2014 3:30pm - 4:10pm
B301

4:10pm

Break
Wednesday May 14, 2014 4:10pm - 4:30pm
Design Summit area

4:30pm

Ceilometer alarm evaluation improvements & effective logging
This session will include the following subject(s):

Alarm evaluation improvements:

Let's review the current state of alarm evaluation and the different approaches of improving it.

- aggresive refactoring approach: move alarms into pipelines
- non-aggressive approach:
- giving alarm evaluation direct DB access
- computing statistics piecemeal - only compute aggregates of the samples that were created AFTER the last alarm evaluation, then combine with the previous aggregates and save them for use in future evaluations
- other ideas and suggestions

(Session proposed by Nejc Saje)

effective logging in ceilometer:

ceilometer is unique in that our code has very few unique channels and (very) heavy load constantly flowing through them. because of that, we often have either way too many logs or no logs at all.

this session hopes to identify what is useful to log and how to effectively implement it without flooding



(Session proposed by gordon chung)


Wednesday May 14, 2014 4:30pm - 5:10pm
B305

4:30pm

Resource Plugin Versioning
This session will include the following subject(s):

Resource Plugin Schema Versioning:

Resources should be versioned to help users determine the portability of their templates across various providers. Heat should also allow for running multiple versions of the same resource in a given installation. The HOT syntax should be extended to allow the user to specify a specific desired version of a resource. If no version is specified, Heat should select the latest supported version of the resource.

This session is to brainstorm how the resource schema version is defined and how a user can discover the resources and the versions thereof supported by a given installation of Heat.

(Session proposed by Randall Burt)


Wednesday May 14, 2014 4:30pm - 5:10pm
B302

4:30pm

Modular, widget-based views and more pluggability
This session will include the following subject(s):

Modular, widget-based views and more pluggability:

Currently, plugins in Horizon can add, remove and replace whole panels. But sometimes an extension would need to display additional information or add a button to an existing view.

I want to discuss an approach to making that possible, by breaking up the views into separate widgets that can then be easily added, modified and moved around by plugins.

Breaking up the more complex views in this way should also make them easier to test and improve code reuse.


(Session proposed by Radomir Dopieralski)

Horizon pluggable content:

Support for pluggable dashboard and panel have been added in Icehouse.

This session is to revisit what has been done to inform the greater audience, and discuss what else is needed to make the pluggable content a success for content provider.

Some topics for discussion:
- how to handle translations
- how to load content provided CSS and Image

(Session proposed by Lin Hua Cheng)


Wednesday May 14, 2014 4:30pm - 5:10pm
B306

4:30pm

Flavor framework for advanced services
This session will include the following subject(s):

Flavor framework for advanced services:

This session should cover requirements and design of 'Flavor Framework' - a new API proposal that should allow users to specify service requirements based on capabilities rather than directly choose provider/vendor

(Session proposed by Eugene Nikanorov)

Virtual Resource for Service Chaining:

Discuss an alternative way of service chaining implementation.
A chain of services can be represented by introduction of the notion of virtual network resource.

(Session proposed by IWAMOTO Toshihiro)

Neutron "Advanced Services" Common Requirements:

Besides basic L2 connectivity, all other aspects of network connectivity are considered as "advanced services" in Neutron. This includes L3/routing and L4-7 (like FWaaS, LBaaS, VPNaaS) features. While each individual advanced service is fairly well defined, there aren't enough normalizing constructs for users to select among different types of the same service (the services may differ in their capabilities), and/or to express the deployment of a combination of services (as a service chain). In addition, a common backend framework does not exist to handle service insertion and chaining. A few proposals have already been made in this context (e.g. service flavors, service context). In this session we will try to build
consensus among the different sub-teams on these proposals and the roadmap for Juno.

(Session proposed by Sumit Naiksatam)


Wednesday May 14, 2014 4:30pm - 5:10pm
B304

4:30pm

Rethinking cross project interactions
When different OpenStack projects need to use each others' services, these are exposed through each project's public API. There is a number of issues that arise form this situation. REST APIs that OpenStack services expose to users are sometimes not best suited for inter-service RPCs. Another issue is that versioned public APIs can be too rigid to evolve with the needs of the codebase. Ultimately, they also usually deal with different levels of abstraction than the user of the service.

There have been several attempts to make this situation better. One of the most notable ones is https://blueprints.launchpad.net/nova/+spec/admin-event-callback-api where we provide an API resource that can be used to notify Nova that something it has requested has happened (or has not happened). Another similar example is qemu-assisted-snapshots introduced in Havana.

In this session, I would like to explore the possible paths from here. It seems that we have already accepted that there is a problem with using public API's for RPC, and there are solutions already in place to make this better. Some ideas:
* Have a tiered REST API with different stability guarantees for components (What about upgrades? versioning?)
* Is it really REST that we need (cross project RPC? This has probably come up before)
* What about clients, do we need a different clinet/SDK

I am proposing this as a Nova session for now, as most of the work around this originated in Nova, and also Nova is usually the central piece that consumes other projects APIs.

(Session proposed by Nikola Đipanov)


Wednesday May 14, 2014 4:30pm - 5:10pm
B303

4:30pm

Functional API testing - post-dev QA vs TDD
Functional API tests for OpenStack core projects are currently maintained in the Tempest project. This is in keeping with Tempest's role in performing post-development QA, and may work well if a given API is developed monolithically. And while tests maintained in Tempest may duplicate some of the testing that is done by an individual project, a common perception is that this duplication serves as a valuable check against unintended regressions in backwards compatibility.

The current approach has some drawbacks, however. Reviewers for a feature that has an API impact can't require that API testing be ready before approval, since Tempest tests can only be run post-merge. The arrangement also complicates test-driven development (TDD) since a feature and its API tests have to be maintained in separate repos. And while a monolithic API may suit the current approach of post-dev QA, it hinders an iterative approach to API development that is being considered by projects like Neutron.

The intent of this session is to discuss the possibility of allowing functional api tests to be maintained in the tree of a given core project instead of in Tempest. Such tests would still need to be runnable by Tempest (e.g. by copying ala oslo or by depending on the core project), and would rely on Tempest-provided infrastructure. Technical considerations aside, the specifics of a project's maintenance of these critical tests would need to be agreed upon to ensure that removing test duplication did not increase the potential for regressions in backwards-compatibility.

(Session proposed by Maru Newby)


Wednesday May 14, 2014 4:30pm - 5:10pm
B301

5:20pm

Ironic and Ceilometer
Ceilometer wants to gather usage data from all the OpenStack services. Ironic is the gatekeeper for remote IPMI access to the machines it has provisioned. Thus, Ironic should emit usage data!

This was discussed briefly at the last summit, and recently the conversation was re-initiated on the mailing list. The Ironic team was not idle on this topic during Icehouse -- we discussed it, checked with two vendors, talked a bit with ceilometer folks, and drafted:
* a specificiation of the message format to pass this data to Ceilometer, and
* a specification for the internal driver API by which all drivers should present their hardware metrics (since different vendors may model it differently).

All the data is linked in the blueprint. Let's review the APIs and get this feature implemented in Juno!

(Session proposed by Devananda)


Wednesday May 14, 2014 5:20pm - 6:00pm
B305

5:20pm

HOT/Artifact repository finalized design
Lets talk turkey about the db schema and api for the HOT (Heat Orchestration Template) artifact repository that was discussed during the mid-summit. Hopefully there will be WiP patches to talk to by then as well.

(Session proposed by Randall Burt)


Wednesday May 14, 2014 5:20pm - 6:00pm
B302

5:20pm

Client side development
This session will include the following subject(s):

Client side development:

A lot of blueprints and issues are dependent of client-side development. It could be a good idea to separate it from the server-side. Due to the integration of Angular it is now easier to provide logic in the browser and it will reduce the complexity of the django application.

A separation between client-side and server-side will also allow us to use javascript dedicated tools without polluting our django app with external dependencies.

Last but not least, putting more load on the client-side is also an efficient way to obtain better performances at scale.

(Session proposed by Maxime Vidori)

Realtime communication and websockets in dashboard:

Many of the dashboards need to update their state when certain events happen. Right now we are doing it in a little bit haphazard way, mostly with polling. This obviously doesn't scale and is not very accurate.

I want to discuss the ways in which we could introduce asynchronous communication into Horizon, taking advantage of modern web technologies, such as websockets, and one or more of OpenStack event systems, possibly Marconi.

(Session proposed by Radomir Dopieralski)


Wednesday May 14, 2014 5:20pm - 6:00pm
B306

5:20pm

Neutron Distributed Virtual Router Progress Update
This session is a status update on the work accomplished by the Neutron Distributed Virtual Router sub-group during the Icehouse release.

We will also discuss about the next steps.

(Session proposed by Swaminathan Vasudevan)


Wednesday May 14, 2014 5:20pm - 6:00pm
B304

5:20pm

Nova V2 on V3 API implementation POC
This session will be to discuss various options for reducing the
maintenance overhead (both short and long term) of supporting the V2
and V3 APIs as well as exploring methods for handling backwards
incompatible changes to the Nova API in the future.

http://lists.openstack.org/pipermail/openstack-dev/2014-March/028904.html

Topics will include

- Nova V2.1 on V3 proof of concept discussion
- Increasing use of common code between V2 and V3 API code bases
- Try to clarify which aspects of the dual maintenance overhead are most concerning and what sorts of planned changes would be affected

(Session proposed by Christopher Yeoh)


Wednesday May 14, 2014 5:20pm - 6:00pm
B303

5:20pm

Rally & Tempest integration (future steps)
Rally is tool that combines all tool together and build simple UI for end users.

You will be able in simple manner to deploy your clouds using your tool (DevStack/TrippleO/Fuel) on hardware that you have (bare metal nodes/ (virtual) servers / OpenStack), and then verify (using tempest) or benchmark it using (tempest/ or rally benchmark) and generate "report" about how cloud work:
e.g.:




Rally uses tempest in 2 different ways:
1) Verification of cloud (installs tempest / generates tempest.conf / run specified set of tests or all / parse subunit results to json and store in Rally DB)
2) Rally has benchmark scenario that produce load using any of tempest unit tests (WIP)


In this session I would like to discuss next topic:
1) What can we move to tempest (e.g. tempest.confg generation)
2) How to simplify tempest.config and build sets of tests that should "pass always"
3) Measuring time inside tempest unit tests (of base actions: e.g. boot vm and wait unit it becomes in ACTIVE state) could be one "action", and this action could be reused in Rally to draw graphics with better details.
4) Future ideas about of integration, and making tempest more integratable.

(Session proposed by Boris)


Wednesday May 14, 2014 5:20pm - 6:00pm
B301
 
Thursday, May 15
 

9:00am

Deploying Ceilometer w/ TripleO & Metering Network Services
This session will include the following subject(s):

Deploying Ceilometer with TripleO:

The effort going into the TripleO incubation effort is yielding a lot of good returns, but the path to getting Ceilometer to deploy correctly has been bumpy and is still being blazed on a daily basis. I'd like to share the progress so far (as of the summit) and discuss what I (and you!) expect the challenges to be as we work to get it in shape.

(Session proposed by Phil Neal)

Metering Network Services:

Currently there are no metrics to monitor network services. Here are some discussion points to go over on what makes sense to meter and implement for juno.

* Firewall as a Service
- type of firewall ( iptables, CSR virtual firewall etc)
- Firewall usage in hourly increments
- # of connections/sec
- Bandwidth


* VPN as a service
- Type of vpn (openswan, cisco etc)..
- # of connections
- Duration of usage in hourly increments
- Bandwidth


* LB as a service
- type of LB ( HAproxy, VPx (Citrix) etc.)
- Number of Connections
- SSL vs no SSL
- How much Bandwidth (traffic going through HAproxy)
- usage in hourly increments
- # of LB pools/ # of VIPs (LB serving 1 server or multiple servers)
- health monitor , figure out the type of probe using


(Session proposed by Pradeep Kilambi)


Thursday May 15, 2014 9:00am - 9:40am
B305

9:00am

Signed Images
This session will include the following subject(s):

Signed Images:

For example consuming an image in an archive (like a tar/tgz) which includes a signed manifest or equivalent mechanism to allow the IaaS provider to only accept images from trusted sources and verify they have not been tampered with.
See http://xml.coverpages.org/DMTF-OVF-v10-DSP0243.pdf

(Session proposed by Fei Long Wang)

Glance Store and future features:

The team recently agreed on pulling glance store out of the Glance code base into its own library. This work has brought lots of cleanups in the store code. This is the perfect moment to finalize the API of the store library and introduce new features to it.

This session will share a plan for migrating glance to this new library and a list of other features that could be supported by glance but depend on the work on this library - random image data access, for example.

(Session proposed by Flavio Percoco Premoli)


Thursday May 15, 2014 9:00am - 9:40am
B302

9:00am

Towards better testing
This session will include the following subject(s):

Towards better testing:

This session is intended to promote a more effective testing strategy for Neutron. The hallmarks of useful testing at both the unit and functional level will be presented. Emphasis will be placed on identifying unnecessary test complexity (with examples) and determining whether it is an indication of poor testability or that the testing need be performed at a different level of abstraction.

Once the theoretical groundwork has been laid, strategies will be discussed for refactoring our existing test suite to reduce its execution time and increase its usefulness. The specifics of writing functional tests (especially of system interaction) will also be discussed.


(Session proposed by Maru Newby)

Neutron QA and testing during Juno cycle:

In the session, the Neutron and QA core teams will come to an agreement on the testing to be developed during the Juno cycle

(Session proposed by Miguel Lavalle)


Thursday May 15, 2014 9:00am - 9:40am
B304

9:00am

Hyper-V Driver new features
New features specific to the Hyper-V compute driver and for Windows guests support.

(Session proposed by Alessandro Pilotti)


Thursday May 15, 2014 9:00am - 9:40am
B303

9:00am

Oslo Library Teams Breakout Session
Several of the teams working on individual libraries will hold simultaneous working group sessions in different corners of the room.

This session will include the following subject(s):

Taskflow 0.2 features/functionality and Q/A:

I'd like to go over the new functionality of taskflow and how it can be used to perform new useful features in openstack projects. This will be useful to expose different projects to what taskflow can be used for and how it can help improve the reliability of the various openstack projects. Also it would be great to gather any feedback to help influence further taskflow development...

Might select from https://etherpad.openstack.org/p/taskflow-atlanta-speaker-ideas (which didn't get accepted) to take ideas from on what to present/show/demo/talk about.

(Session proposed by Joshua Harlow)

Namespace Config Options (oslo.cfg options):

The sample config files for the oslo libraries (oslo.messaging is the large offender) as well as the oslo-incubator files seem to occupy a large amount of the [DEFAULT] section of the configuration tree. In most cases these options could be moved to their own namespaced sections (e.g. [oslo_messaging]).

Ideally there should be a nomenclature (perhaps supporting something akin to oslo. in the config if possible, ConfigParser is a bit picky about this syntax) that makes it clear where the options are coming from when looking at either a sample or live configuration file.

This session can likely be combined elsewhere or be deferred to IRC / Dev Lounge discussion.

(Session proposed by Morgan Fainberg)

oslo.vmware - Adoption and Future:

We need to identify how we can utilize oslo.vmware to speed up feature additions to different projects like Nova, Glance, Cinder etc. Talk about what code makes sense to move to oslo.vmware and strategies to quickly increase adoption.

(Session proposed by Davanum Srinivas)

What should we do with Oslo's context?:

There is a context module in the incubator. We've gone back and forth on whether or not it is useful as-is. It's being synced into several projects now, but it it actually used? We need to define the API between the context and logging's formatter class, can we use the Oslo version as a base class?

(Session proposed by Doug Hellmann)


Thursday May 15, 2014 9:00am - 9:40am
B306

9:00am

Vulnerability management in Juno
The vulnerability management team will discuss changes to the tooling and the workflow, to put in place during the Juno cycle.

That includes:
- Icehouse retrospective
- improvements in the vulnerability management process
- definition of the security-supported set of projects and branches
- using a private Gerrit to review security patches and OSSA drafts
- publish OSSAs in a read-only reference location
- security patches test infrastructure

(Session proposed by Thierry Carrez)


Thursday May 15, 2014 9:00am - 9:40am
B301

9:50am

Patching the documentation process
Discuss how to improve the documentation process including markups, workflows, contributions, conventions, and reviews.

(Session proposed by Matt Kassawara)


Thursday May 15, 2014 9:50am - 10:30am
B301

9:50am

Tasks Review and Taskflow
This session is created to merge the discussion of Taskflow and image validation on import.

(Session proposed by Mark Washenberger)


Thursday May 15, 2014 9:50am - 10:30am
B302

9:50am

Sharing the load of operational responsibilities
Neutron has historically depended too much on heroic effort. Many key operational responsibilities - notably fixing gate issues and pushing merges during crunch time - are undertaken by a small group of overworked contributors. This is not sustainable/scalable/fair, and continuing with this approach risks the health of the project.

The intent of this session is to formalize the operational requirements of the Neutron project and to discuss how the community can best be organized to meet them.

(Session proposed by Maru Newby)


Thursday May 15, 2014 9:50am - 10:30am
B304

9:50am

Libvirt driver roadmap for Juno
A session to discuss changes and improvements to the Nova libvirt driver we want to see done in Juno.

The session will be lead by Daniel P. Berrange

(Session proposed by Nikola Đipanov)


Thursday May 15, 2014 9:50am - 10:30am
B303

9:50am

Testing pre-releases of Oslo libs with apps
For integration tests, devstack installs Oslo libraries from source. We don't have a similar way to run an application's unit tests with the source version of the various libraries. Partly as a result we had 2 cases where new releases of Oslo libraries broke unit tests in applications.

As part of releasing oslotest we have set up a few jobs to allow the oslotest to be gated on the unit tests of other projects, in an attempt to avoid making changes in the test library that break running tests.

I would like to discuss the pros and cons of applying the oslotest technique to the other Oslo libraries.

(Session proposed by Doug Hellmann)


Thursday May 15, 2014 9:50am - 10:30am
B306

9:50am

Scheduling Automated Tasks Service
We need a way of scheduling tasks like full/incremental backups or other tasks that may come up in the future.

Existing Blueprints:
https://blueprints.launchpad.net/trove/+spec/scheduled-tasks
https://blueprints.launchpad.net/trove/+spec/automated-backuping

Things to consider:
- Make sure not to run all automated tasks at the same time on a host. (Could over load a host)
- Should be pluggable interface for deployment options available on how to schedule backups.


Questions to answer:
- What type of jobs need to be scheduled?
- How granular the schedule should be?
- Maintenance windows a user can set on their instance?
- What technology options do we have for scheduling the tasks?


(Session proposed by Craig Vyvial)


Thursday May 15, 2014 9:50am - 10:30am
B305

10:30am

Break
Thursday May 15, 2014 10:30am - 11:00am
Design Summit area

11:00am

Adding functional operations to glance API
I have some ideas/plans in mind:

Use case/features
-------------------------------------------------------------
View/search image content (file and application level)
View image similarities
Compare images
Compound image support (something like http://docs.docker.io/en/latest/terms/layer/ )
Image de-duplication
Move images across repositories (delta)
Version control
Convert Image format (it's landing via async-task mechanism)

They are all the functional things we need to do, where do functional-operations-oriented features fit in the API?
(And I believe image-deactivate case is fit this topic as well btw)

The challenge for fitting them into Glance current API model is that the API (and domain model probably IMO) is not robust and direct enough for some of those functions, since RESTful interface style makes now API model is very CRUD-centric.

Questions:
1. Are they fit into current RESTful CRUD-centric API? What need to change on the API model to make them fit? Any challenge of making it make sense with the existing API model?

2. Do we need to adding extension mechanism to Glance? Does an API level extension is enough for us? or whole-stack one (API+domain+DB)?
Gain:
- Preventing change main resource model on domain and DB level for ever functional features, e.g. Image, Membership, Tag, Task and etc.. Feature image-deactivate is this case.
- Preserving support for the existing API. Just needs some minor changes.
- Easily to make other people put whatever they want in an extension. (of cause we need to review it before merging)
Loss:
- Extension is a dumping ground for *every* type of operation, so the it can be all over the place in terms of style. But *seems* we don't need a lower barrier to entry against people think of extensions as being a lower barrier to entry than regular API stuff in the past.


BTW, I'd like to discuss above features in a dedicated talk with you.

(Session proposed by Zhi Yan Liu)


Thursday May 15, 2014 11:00am - 11:40am
B302

11:00am

Discussion/design talk of Vinz code review system
This session would be used as an organized discussion with the Infrastructure community about the Vinz code review system that is proposed for development as a replacement of Gerrit.

This would include discussion of the following things:
- Architecture
- Cross system communication (oslo.messaging and gearman)
- Goals of project
- Roadmap of development and implementation.

(Session proposed by Philip Schwartz)


Thursday May 15, 2014 11:00am - 11:40am
B301

11:00am

Loadbalancer as a Service (LBaaS)
This session is dedicated to a basic changes planned to object model and API. Also a project road map will be discussed.


(Session proposed by Eugene Nikanorov)


Thursday May 15, 2014 11:00am - 11:40am
B304

11:00am

Improve performance of live migration on KVM
We still have many problems using live migration, especially block migration.

I would like to disccuss how to improve performance of live migration.

For example, there are lots of options in libvirt migration command, migrate-setmaxdowntime, migrate-setspeed etc..

With these options, we would expect better performance of live migration.

(Session proposed by SeungjinHan)


Thursday May 15, 2014 11:00am - 11:40am
B303

11:00am

OpenStack cross service/project OpenStack profiler
I and my colleagues are working on pure OpenStack profiler that can be merged in upstream & even run in production to allow us to get traces of request cross all services.

The idea is similar to Tomograph, that allow you to get such output:
https://launchpadlibrarian.net/156337955/sql.pdf

But instead of usage "Zipkin" and it's notification (that are quite hard integratable). We are going to use oslo.messaging notify api + Ceilometer, and script that will fetch data from Ceilometer and draw output graphic similar to Zipkin output.

Library is here:
https://github.com/pboris/osprofiler

currently we are testing it, and hope to get some demo soon.

(Session proposed by Boris)


Thursday May 15, 2014 11:00am - 11:40am
B306

11:00am

Testing Trove
There are a couple of areas in Trove where we need to up our Testing/QA.
Specifically let's discuss the following:

1. Increasing Tempest Integration Test Coverage:

https://etherpad.openstack.org/p/trove-tempest-items identifies the gaps that we have in our integration test coverage.
What can we do to more quickly address some of these?

2. Testing upgrades:

We will need to support testing upgrades from IceHouse to Juno.
How can we leverage grenade to do this?

3. Testing requirements for all datastores:

Trove supports several data stores today.
However, we don't actually test any of the code paths that support the data stores in the gate.

Deployers of Trove should feel pretty confident that the functionality that exists actually works.
How do we fix this problem?

(Session proposed by Vipul Sabhaya)


Thursday May 15, 2014 11:00am - 11:40am
B305

11:50am

Poking image filesystem
Currently there is no any "poke at image filesystem" feature in Glance. AFAIK the main argument about it not belong in glance is that some people think "Glance should never look at the filesystem". But I see there are some really useful functions based on this fundamental, For example:

- View/search image content (file and application level)
- View image similarities
- Compare images
- Compound image support (something like http://docs.docker.io/en/latest/terms/layer/ )

Above features need filesystem indexing and/or accessing operations which poke at the image filesystem.

So I think the gain and loss of this direction is fifty-fifty. And I believe the features around "poke at image filesystem" could get sundry concerns from folks, so we need a place to start the conversation I think.


BTW, I'd like to discuss above features in a dedicated talk with you.

(Session proposed by Zhi Yan Liu)


Thursday May 15, 2014 11:50am - 12:30pm
B302

11:50am

StoryBoard: current status & Juno plans
StoryBoard is a next-generation task tracker for OpenStack, with the long-term goal of replacing our current usage of Launchpad.

During the Icehouse cycle, a team was assembled to work on StoryBoard. The django POC was reimplemented as an API server and a javascript webclient, and is continuously-deployed in production. Storyboard is currently dogfooding itself, and the Infrastructure team is expected to move to using it really soon now.

This session will present the current state and try to brainstorm a vision for the Juno cycle: key features to implement, milestones to reach with the goal of moving more projects to StoryBoard at the start of the K cycle.

(Session proposed by Thierry Carrez)


Thursday May 15, 2014 11:50am - 12:30pm
B301

11:50am

Authorization
https://etherpad.openstack.org/p/juno-keystone-authorization

This session will include the following subject(s):

RBAC and Policy:

This is a collection of related topics that have come up in previous summits and not yet resolved:

Scoping Role definitions to services (and endpoints, and projects)
Endpoint binding of Tokens
Fetching the appropriate policy file for an Endpoint
Parsing policy and calculating what permissions need to be delegated to perform an action on behalf of a remote user


(Session proposed by Adam Young)


Thursday May 15, 2014 11:50am - 12:30pm
B306

11:50am

Modular Layer2 Agents
This session combines submissions centered around ML2 agents.

This session will include the following subject(s):

Chaining of basic Networking services with OVS:

More and more features are adding flows to OVS bridges [br-int, br-tun etc] which impacts performance, scalability and troubleshooting. In this session we discuss the design model where each of these core feature uses its own OVS bridge to isolate its flows. Discussion would revolve around following key topics:

- Each feature/service creates its own OVS bridge and adds flows to it.
- These OVS bridges can even be hosted in a separate service VM to allow a scale-out model.
- Test results from a prototype using such a deployment. Current impetus for this came from work on OVS-Firewall-Driver and currently am working on a prototype that implements OVS Firewall using a separate bridge. I expect the prototype and test results to be ready by the summit and plan to share them during this discussion.

(Note: This can be collapsed into a similar topic, esp OVS-Based security groups)

(Session proposed by Vishal Thapar)

OVS-based security groups:

Blueprint purpose: To support the security groups extension in the OVS neutron agent through OVS flows using the existing OVS library with feature parity to the existing iptables-based implementations. In Icehouse, the existing openvswitch plugin is being deprecated, so the blueprint is compatible with the ML2 plugin with the openvswitch mechanism driver.

Going forward: We weren't able to progress with this blueprint in Icehouse due to OVS 2.1.0 dependency which was not released until late March. We would like to continue blueprint design discussion and implementation in Juno.

For more information see https://blueprints.launchpad.net/neutron/+spec/ovs-firewall-driver and https://wiki.openstack.org/wiki/Neutron/blueprint_ovs-firewall-driver

(Session proposed by Amir Sadoughi)

Modular L2 agents :

In this session we consider various aspects of developing a modular L2 agent. In particular we look into:

- combining openvswitch, linuxbridge, hyperv, ofa L2 agents
- adding plugable support for SR-IOV cards
- adding plugable drivers for firewall, QoS, etc

(This may not need a whole session and could be part of a session on similar topics.)

(Session proposed by Mohammad Banikazemi)


Thursday May 15, 2014 11:50am - 12:30pm
B304

11:50am

limited conductor API
After move the DB access from compute node to conductor, compute node have no DB access any more.

However, currently the conductor has no limitation to the DB access when it proxy for compute node. For example, a compute node can update the compute node information for other compute node, can update the migration information, basically it can do everything.

This means a compute node can impact cloud-wide stats, this is not secure considering potential Hypervisor compromise , thus we need enhance nova to limit the compute node DB privilege.

Although the discussion of signing message (https://blueprints.launchpad.net/oslo.messaging/+spec/trusted-messaging) are still on-going in OSLO, but I think it will be benefit if we can discuss what should be done on conductor and compute manager, to limite the DB access from compute node manager. The reasons are:

a) It will not easy to achieve DB access limitation for compute node, early discussion can help us find out the gap and estimate the effort needed.

b) Clarification of the requirement will help us to avoid new code merged that requies global information access from compute node.

c) This can be a usage case for trusted messaging and can provide helpful feedback to that blueprint.


(Session proposed by jiang, yunhong)


Thursday May 15, 2014 11:50am - 12:30pm
B303

11:50am

Replication Next Steps
As we complete the work for version 1 Replication targeted at MySQL, it makes sense to discuss the follow on work indicated in https://blueprints.launchpad.net/trove/+spec/replication-v1 as well as support for other datastores.




(Session proposed by Doug Shelley)


Thursday May 15, 2014 11:50am - 12:30pm
B305

12:30pm

Lunch
Thursday May 15, 2014 12:30pm - 1:30pm
Expo Hall, Level 1

1:30pm

Federation
https://etherpad.openstack.org/p/juno-keystone-federation

This session will include the following subject(s):

Future Enhancements to Keystone Federation Support:

In IceHouse we created a first draft of Federation support for Keystone, in this session, we would like stakeholder feedback in the following areas:
How can we improving the mapping function? as it is currently limited to groups and user. Can we remove the dependency of requiring an unscoped token? Can we support projects and domains in mapping assertions? Is there another federation protocol that we would like to support?

(Session proposed by Steve Martinelli)

Federation within a private cloud:

For large private clouds (e.g. many geographical dispersed regions), we don't currently have a federated solution. Out of the box, the standard deployment would be a central keystone, with other endpoints in the regions. Alternatively, some companies create their own pseudo-federation by placing a keystone in each regain and doing DB replication (with throttles depending on which table you are talking about).

What is really required is to have some kind of "keystone trusting", so that a token issued by one keystone would be accepted by another within the private cloud. This is different to the Public Cloud Federation model, where it is acceptable to re-authenicate (with a SAML assertion) as you hit each new OpenStack cloud.

(Session proposed by Henry Nash)


Thursday May 15, 2014 1:30pm - 2:10pm
B306

1:30pm

Implementing state management for quotas
One of the problems with managing a large private cloud is integrating quota management into the existing financial process.
When one of our Projects on our internal cloud wants to increase their quota they’ll need to file a request. That request will be compared against projected cluster capacity as well as certain financial models. If the request falls within certain parameters it’ll need larger finance approval before the quota can be allocated. There are a number of capacity folks who would be handling these requests, so there could be a race condition when multiple Projects request capacity at the same time.
So not only do we need a way to grant and track quota increases, but also to have a concept of state management within a given quota request. The advantage of state management is an enterprise can track why and when a given quota increase was requested and granted. Especially if there’s a field to track an external reference ID (like a bug/ticket number). The big change is that we will no longer have one item in the DB per-Project-per-resource, but instead it’d be per-Project-per-resource-per-request. This means we’d also need to extend nova to support the concept of ‘Soft’ and ‘hard’ quota. Hard quota being what you can actually allocate against, and ‘soft’ quota would let you see what you have + what’s in the pipe for approval.



(Session proposed by James Penick)


Thursday May 15, 2014 1:30pm - 2:10pm
B303

1:30pm

API tests with JSONSchema
Now Tempest contains two kinds of API definitions with JSONSchema for Nova project.
One is used for generating negative tests automatically.
The other one is used for checking the response body in API test.

API definitions of the first one represent both the request body formats and error
response codes(HTTP 404, etc.) of each API. Tempest operates negative API tests based
on them and check whether the response code is the expected one. The API definitions
is being implemented now.

The second ones represent both the response body formats and success response codes(HTTP200,
etc.) of each API. The REST clients check the response based on each API definition and if
receiving a bad response(lack of necessary parameters, etc.), Tempest raises an exception.
By this behavior, Tempest is blocking the backward incompatible changes for Nova project.

I'd like to discuss some points for this topic:

* How to integrate API definitions
API definitions of negative tests are stored under etc/schemas/compute/ and the other
ones are done under tempest/api_schema/compute/. The description formats are different,
but it would be nice to describe both of them in each API file for its maintenance.

* Port API definitions
Nova also contains API definitions of JSONSchema for the request validation of v3 API.
So we will be able to port API definitions of request from Nova to Tempest for negative tests.

On the other hand, it would be good to port API definitions of response from Tempest to Nova
for API documentation. Nova contains template files of API response body and they have/should
been used for Nova original integrated tests(not Tempest), but these template files sometimes
were wrong because some tests did not use them and Nova tests could not detect them.
If porting from Tempest and using them for the tests, it would make Nova test quality better
because these definitions are already verified.

* Apply this framework to the other projects?
JSONSchema is a common python library and we use it for Tempest.
As the above description, we can reuse API definitions, which are described with JSONSchema,
for multiple use cases. However, the other project(Ceilometer, Ironic, etc.) is implemented
with WSME instead of JSONSchema. So if applying this to API tests of these projects, we use
the definitions once only.

(Session proposed by Ken'ichi Ohmichi)


Thursday May 15, 2014 1:30pm - 2:10pm
B301

1:30pm

Releasing and backward compatibility
1) releasing and versioning

Sahara is now integrated project and will be part of the integrated Juno release, so, we need to adjust and define releasing/versioned for our subprojects:

* sahara-image-elements
* sahara-extra
* sahara-dashboard (before merging it to Horizon)

===========================

2) Backward compatibility and Hadoop cluster upgrade

As Sahara is integrated project now we can't just remove old version of hadoop and say to use new one. Need some way to migrate existing clusters or support all released versions of hadoop (with all libraries included) during deprecation period (one release?).


(Session proposed by Sergey Lukjanov)


Thursday May 15, 2014 1:30pm - 2:10pm
B304

1:30pm

Swift core principles and growing pains
A combined discussion about where we started, how we've grown, and current community problems we face.

This session will include the following subject(s):

Swift Growing Pains:

While swift continues to be a stable and mature project, we have had a fair share of growing pains over the past year. In this session I would like to spend time hearing from other users as well, and see how we can address some of these pains.

Some examples include:

1. Bugs making it to production
2. Having long running feature branches
3. Code reviews

(Session proposed by creiht)

Swift core principles:

When we began this journey almost 5 years (where has the time gone?) ago in a small office, we had a set of core principles that guided the design of Swift. I would like to revisit those principles and use that as a starting point to codify a set of core principles of swift. As swift continues to grow, and more developers work on swift, I think this will help us all to be on the same page when it comes to the next 5 years of growth.

(Session proposed by creiht)


Thursday May 15, 2014 1:30pm - 2:10pm
B302

1:30pm

Clustering Next Steps
the next steps for clustering in trove for datastores.

deciding on the api, how to handle cross az/region, how to handle coordination of nodes, etc.

(Session proposed by Auston McReynolds)


Thursday May 15, 2014 1:30pm - 2:10pm
B305

2:20pm

Locally-managed identities
https://etherpad.openstack.org/p/juno-keystone-locally-managed-identities

This session will include the following subject(s):

Keystone support for One Time Password ( OTP):

Keystone authetnication model can be easily extended to support OTP (One time password). OTP doesn't need to be mandatory so it won't break existing deployment. This can be used as a building block to support Multi factory authentication (MFA).

Few use cases which will benefit from OTP
* Users password update. If user has enabled OTP, then horizon can ask for OTP besides old password
* Any self service operation
* Initial login process in console




(Session proposed by Haneef Ali)

Password Policy and Lifecycle Management:

For users managed by Keystone, we need to have password policy and lifecycle management capability in order to satisfy the enterprise security requirements. The challenge is inconsistent user experience if we have a mixture of Keystone-managed and 3rd party managed users. But if we can make these features configurable (say per domain) we should be OK. Lets discuss what we can do in Juno and beyond.

1. Account lockout after x consecutive failed login.
2. Force change password on the next login.
3. Password expiry.
4. Password recovery. (Knowledge-based? i.e. security questions)
5. Password composition enforcement. (i.e. min and max length, must consist of alphnumeric, least 1 special-char, etc)
6. Password rotation

(Session proposed by Guang Yee)


Thursday May 15, 2014 2:20pm - 3:00pm
B306

2:20pm

Multi-Volume Snapshots
Nova currently provides several mechanisms to create a snapshot of a running instance. However, an instance may be using multiple volumes. As none of the current snapshot mechanisms provides a way to obtain a consistent set of snapshots for all of the attached volumes, we need to add a way to perform a quiesce-only operation in libvirt. Once such a capability is introduced in libvirt, Nova will be able to utilize it during the snapshot process to create a transactional snapshot of all volumes. The various snapshot calls are expected to be aggregates to a single shared implementation.

On the Glance side, the set of snapshots could be treated as a single entity using the new Artifact design.

(Session proposed by jbernard@tuxion.com)


Thursday May 15, 2014 2:20pm - 3:00pm
B303

2:20pm

Negative Testing: Fuzzy Test Framework
Building a fuzzy test framework for security testing out of negative test generators and stress test framework.
The main effort of this blueprint will focus on test data generators and validators. The generators can produce random data or pattern based data. After some runs or after every run a validation must be done if the service is still available. This can be done via tempest test cases.

Open topics for the discussion:

- Negative testing coordination of existing tests
- XML suppport
- Generator design for fuzzy patterns
- Usage of the stress test framework

This session will include the following subject(s):

Fuzzy test framework :

Building a fuzzy test framework for security testing out of negative test generators and stress test framework.

The main effort of this blueprint will focus on test data generators and validators. The generators can produce random data or pattern based data. After some runs or after every run a validation must be done if the service is still available. This can be done via tempest test cases.

This session would be most likley a shared session between OSSG and QA.

(Session proposed by Marc Koderer)

Fututre of negative testing and next steps:

We already have a framework that supports the creation of negative test out of interface descriptions.

This session will focus on the next steps and how we can encourage people to get involved with that.

Open topics:

- Coordinate the transformation of existing tests
- XML suppport?
- Merging interface definitions for API validation tests

(Session proposed by Marc Koderer)


Thursday May 15, 2014 2:20pm - 3:00pm
B301

2:20pm

CI/gating and plugin requirements
1) CI/gating, 3rd party testing

We should discuss our current coverage by integration tests (especially in Tempest) and discuss plans for improving it in Juno.

===========================

2) Plugin requirements and lifecycle policies

We should discuss policy for adding new plugins, minimum functionality for adding new plugin, deadline for proposing new plugins and etc.

(Session proposed by Sergey Lukjanov)


Thursday May 15, 2014 2:20pm - 3:00pm
B304

2:20pm

Swift Dev/Ops Session
Many times we've heard a desire for more feedback and interaction from users. However, their attendance at design summit sessions is met with varied success.

However, last summit, by happy accident, a swift session turned into a something a lot more user driven. A competent user was able to describe their use case, and the developers were able to stage a number of question to them. In this way, some of the assumptions about the way certain things were implemented, and the various priorities of future plans became clearer.

This session proposes to run such an an "ops" session for the swift project.

Primarily, the purpose of this session is to for developers to ask the operators to answer questions, and request information. However, operators could also be allowed to tell the developers things (give feedback) as a secondary purpose.


https://etherpad.openstack.org/p/ATL-ops-dedicated-design-summit-sessions

(Session proposed by Tom Fifield)


Thursday May 15, 2014 2:20pm - 3:00pm
B302

2:20pm

Monitoring in Trove: Of DBAdmins and Buses
Trove today has very limited monitoring through agent heartbeats.
Going forward, this will be somewhat insufficient if we want to achieve goals like active slave promotion, failover and agent remediation.

Specifically we should discuss improving monitoring along these fronts:

- Better Agent Monitoring, and remediation:
What should we do about "Lost Agents"

- Upgrade Monitoring:
How do we ensure that all agents have been upgraded to a "baseline" version correctly.
How do we deal with agents that haven't?

- Connectivity monitoring:
The datastore agent might be up and running, but how do we monitor instances to ensure that a customer is actually able to connect to it?

- Replication Monitoring:
How do we monitor the master / slave, and achieve quick and active failover from them master to the slave in case the master goes down?
How do we provision a new slave to replace the old one?

- Self healing clusters:
How should we monitor cluster nodes and what is our remediation strategy in case a cluster node goes down?

Etherpad at: https://etherpad.openstack.org/p/TroveMonitoring


(Session proposed by Nikhil)


Thursday May 15, 2014 2:20pm - 3:00pm
B305

3:10pm

Hypervisor power management
All hypervisors are always powered on and consumes power irrespective of load on them. Even if there are no instances (VMs) running on a hypervisor, it will still consume power leading to wastage of power costs. This blueprint aims to provide a mechanism to check if there are any unused hypervisors and power off them using custom hypervisor power driver. This helps in saving power consumption costs. Whenever required, nova-scheduler will call the driver this hypervisor power driver to power on the hypervisor without any manual involvement.

(Session proposed by Chilumukuru Amarnath)


Thursday May 15, 2014 3:10pm - 3:50pm
B303

3:10pm

Upstream chat with Mike Bayer
Mike Bayer, author of dogpile, sqlalchemy, sqlalchemy-migrate, and alembic will be at the summit to discuss upcoming changes and our needs for some of the tools that he maintains.

See https://etherpad.openstack.org/p/juno-oslo-bayer

(Session proposed by Doug Hellmann)


Thursday May 15, 2014 3:10pm - 3:50pm
B306

3:10pm

How to improve the UX of our testing tools
We have currently standardize our test launcher under testrunner and use tox to launch our different testing environements. We advise as well to use devstack for openstack developers for development.

They have both some issues for the user/developer experience for example when there is a syntax error in the tests testrunner just spit out a big blob of characters without any other feedback.

tox on the other hand tend to breaks between releases and among different issues we currently have to pin ourself to 1.6.1, something the new developer would not necessary know.

devstack on the other hand seems to become more oriented to ensure that the gating is right and not so much anymore for developers.

This session would be to dicuss how we can improve all of this so new (and not so new) developers don't have to know about all those quirks and can develop/debug easily their code for openstack.


(Session proposed by Chmouel Boudjnah)


Thursday May 15, 2014 3:10pm - 3:50pm
B301

3:10pm

Scalable Sahara and further OpenStack integration
1) multi-process execution (sahara-api, sahara-engine)

We should discuss design of multi-engine support in Sahara. In fact design was already discussed before the previous summit and on it, but probably we'll have some corrections.

Current multi-engine approach:

* sahara-api holds api, validation and read operations;
* sahara-engine holds all other operations like clusters provisioning and etc.

===========================

2) guest agents (MQ-based, Marconi-based)

As it was discussed on previous summit we have some connectivity issues while using direct access from controllers to VMs for SSH access, so, we're starting discussion around the Unified Agents approach. We should discuss plans about guest agent for Sahara.

==========================

3) further OpenStack integration

* Heat
** hardening of Heat-based provisioning
** testing in gate of Heat-based provisioning
** Sahara resource in Heat
* Ceilometer
* Ironic

(Session proposed by Sergey Lukjanov)


Thursday May 15, 2014 3:10pm - 3:50pm
B304

3:10pm

Making Swift docs better
Lets dive in and look at the current state of swift docs. How can we make them more accessible? Where are we missing docs, or docs are out-dated? More people land on http://swift.openstack.org landing page than all other openstack docs by an order of magnitude. Lets see if we can make that a better experience.

(Session proposed by creiht)


Thursday May 15, 2014 3:10pm - 3:50pm
B302

3:10pm

Datastore Versioning / One Impl to Rule them All
Let's spend some time discussion datastore versioning. Specifically let's discuss:

(1) if a datastore has distro packages, but the latest version isn't in the repo, is the accepted approach to use backports if possible? if it's not in backports then what?
(2) how do we indicate what datastore versions are supported in a particular manager impl?
(3) what is the line between "i'll slightly modify the manager to support this new version" vs. "make a new manager"?
(4) how to handle configuration-group changes across minor versions.
(5) how to handle non-distro packaging when it comes the 'packages' column, upgrades, etc.

--------------------------

Let's also talk about coalescing similar datastores, if we haven't already achieved consensus on this.

Currently we have percona and "mysql" (stock oracle). These values may have slightly different tweaks to some config values, as well as different /configurations, images, but other than that, the code is all the same.

Id like to propose that we limit ourselves, including our tests, to one mysql. The number of permutations for testing will rise dramatically as we add different versions and impls.

The differences can be in the form of best practices docs, rather than special options in cfg, /configurations, image, and elsewhere.

*** FWIW the same can be said about toku vs 10gen

(Session proposed by Michael Basnight)


Thursday May 15, 2014 3:10pm - 3:50pm
B305

3:50pm

Break
Thursday May 15, 2014 3:50pm - 4:10pm
Design Summit area

4:10pm

Volume replication - continued
Work on volume replication started in Icehouse following discussions in HK. A blueprint (https://blueprints.launchpad.net/cinder/+spec/volume-mirroring) and code (https://review.openstack.org/#/c/64026/) were discussed and reviewed, but some questions have been raised toward the end of the development cycle, so it was decided to iron-out the issues at the Juno summit.
This session is revisit the design and reach agreement the implementation details for supporting volume replication in Cinder.
co-submitted with Jay Bryant and Bill Owen

(Session proposed by Ronen Kat)


Thursday May 15, 2014 4:10pm - 4:50pm
B305

4:10pm

SR-IOV support
Discuss networking SR-IOV support in neutron and nova. Especially:
-- requirements of neutron SR-IOV to the nova generic PCI passthrough support
-- interactions between neutron and nova to achieve it
-- neutron ML2 mechanism drivers in support of SR-IOV


(Session proposed by Robert (Baodong) Li)


Thursday May 15, 2014 4:10pm - 4:50pm
B303

4:10pm

rpc proxy(oslo.messaging)
Proxying RPC over unix domain socket between two Linux netns.


Some openstack features are implemented in instance VM(s).
So it is necessary for openstack-servers like neutron-server need to issue RPC from openstack management network into openstack tenant networks which is strictly isolated.
So there needs some way to proxy RPC between openstack management network and tenant networks.
This is a requirement for servicevm framework for neutron
https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms

One possible(and proposed) way is to use unix domain socket to relay RPC messages.


(Session proposed by Isaku Yamahata)


Thursday May 15, 2014 4:10pm - 4:50pm
B306

4:10pm

Tempest GUI, client, server
Tempest is a great tool for verifying existing OpenStack clouds. So Tempest is not only for developers but also operators.
However, it is hard to use Tempest for operators because it is difficult to use for people not familiar with the development tools such as python and testr.
So I propose a Tempest GUI. It reduces obstacles for running Tempest tests. We will talk about the design of the GUI, tempest-pythonclient and Tempest-server in this session.


(Session proposed by Masayuki Igawa)


Thursday May 15, 2014 4:10pm - 4:50pm
B301

4:10pm

UX improvements
1) Balancing Expert vs Novice Workflows

As Sahara grows and we add more capability, how do we balance the needs of users ranging from expert to novice?

Experts may know about and want control over fine details of cluster configuration and deployment.
A novice knows not much more than the amount of resources available to them.

Can we find ways to do both well?

===========================

2) Get rid of / improve Image Registry

* Get rid of Image Registry - differentiate images by name pattern or etc.
* Remove hard dependency on user in image registry in case of Heat provisioning engine

TL;DR

Due to the moving on using Heat instead of direct provisioning, we could now rely on user created by Heat, so, the only profit of Image Registry is handling tags for different plugins. Probably, we should take a look on overall UX of Image Registry mechanism in this case. Currently, the main role of Image Registry is just to not display all images in dropdowns in UI.

===========================

3) Sahara dashboard in Horizon

Short discussion of status / plans for merging sahara-dashboard into the horizon.

(Session proposed by Trevor McKay)


Thursday May 15, 2014 4:10pm - 4:50pm
B304

4:10pm

Arch of the Swift Object Server DiskFile API
This session will include the following subject(s):

Arch of the Swift Object Server DiskFile API:

A discussion of the current state of Swift's Object Server DiskFile API, its interfaces, use cases, existing implementations.

(Session proposed by Peter Portante)

Swift Pluggable BackEnds (PBE):

Discuss the design and current commit out for review on PBEs (pluggable back ends) for the account and container servers.

See https://review.openstack.org/47713

(Session proposed by Peter Portante)


Thursday May 15, 2014 4:10pm - 4:50pm
B302

5:00pm

DRBD for local and remote replication
DRBD is a block replication technology that became part of the Linux
kernel with its 2.6.33 release. In the upcoming DRBD release (version 9),
DRBD will support real-time mirroring (synchronous and asynchronous)
to multiple nodes simultaneously.

We propose a cinder driver that uses DRBD to replicate local node
storage, where the local node's storage is managed by LVM.

In particular we are looking for a discussion on

* Can this be achieved in a generic way, so that LVM is not set in
stone

* Might this approach be generalized for remote replication
(disaster recovery)

We will have a few slides about DRBD 9, drbdmanage and a short demo of the
proof of concept code. (~15 Minutes)

(Session proposed by Philipp Reisner)


Thursday May 15, 2014 5:00pm - 5:40pm
B305

5:00pm

Tuskar-UI and its relationship to Horizon
The Tuskar-UI is currently implemented as another dashboard within the OpenStack Dashboard and is generally considered, somewhat inaccurately, to be the UI for the Tuskar project. The code of Tuskar-UI adds another dashboard entitled Infrastructure which deals with OpenStack deployment management (which involves cooperation across multiple services) but also with other infrastructure pieces (such as node management)... and it is expanding.

The nature and context of the Infrastructure dashboard's content, makes it quite different to the Project and Admin dashboards, so it makes sense that they don't appear together. Also, the role of users who engage in Infrastructure management is different from roles enabled by the rest of OpenStack Dashboard.

The goal of this session is to figure out how to approach what is currently called Tuskar-UI. Should it simply be a plugin to the OpenStack Dashboard? Should it be standalone UI like OpenStack Dashboard, sharing same assets, based on Horizon framework, under the Horizon program? How should it all work together?

-- Jarda

(Session proposed by Jaromir Coufal)


Thursday May 15, 2014 5:00pm - 5:40pm
B306

5:00pm

Nova V3 API
A discussion on what we need to achieve in order to be able to release
the Nova V3 API. It would cover areas such as:

- Input from V2.1 on V3 discussions
- Implementation
- nova-network support
- Tasks API
- python novaclient v2/v3 stability
- Any outstanding warts with API (eg datetimestamp consistency)
- Documentation
- Specification
- V2 to V3 API transition documentation
- Testing
- API and scenario testing
- Criteria for releasing the Nova V3 API


(Session proposed by Christopher Yeoh)


Thursday May 15, 2014 5:00pm - 5:40pm
B303

5:00pm

Stable branches maintenance
The stable maintenance team and release managers will gather to discuss the havana and icehouse stable branches schedules, as well as improvements to the stable branch maintenance process.

(Session proposed by Thierry Carrez)


Thursday May 15, 2014 5:00pm - 5:40pm
B301

5:00pm

Future of EDP: plugins, SPI, Oozie
1) Plugins SPI review

Sahara consists of different layers:

1. cluster provisioning
2. EDP

Most probably new layers will appear:

3. hadoop security management
4. non-hadoop activities

How plugin SPI should look to support all kinds of communication? Should it be one SPI or several SPIs? Do we allow communication by naming convention (e.g. expect something with given name in extra field)?

===========================

2) EDP plugins - get rid of Oozie hard dependency

We should make EDP pluggable to be able to use not only Oozie in EDP. It's needed to support running Spark / Storm workloads in future using EDP on top of Sahara's provisioned clusters.

===========================

3) Future of EDP

Now we assume that:
1. oozie is used for workflow management
2. all plugins potentially support all job types (may be not implemented)

Do we continue with such assumptions?
What other job types need to be added in Juno?

(Session proposed by Andrew Lazarev)


Thursday May 15, 2014 5:00pm - 5:40pm
B304

5:00pm

Swift Storage Policies
This session will include the following subject(s):

Swift Storage Policies:

We'll talk about the overall design and status of the implementation and anticipate a good technical discussion on usage models that are both immediately available with policies. We will also talk about future work and other possible usage models enabled by policies.

(Session proposed by paul luse)

Swift Erasure Codes:

Multiple companies have been working together to design an EC implementation for Swift that leverages Storage Policies and fit well into the existing Swift architecture while at the same time is optimized for performance (big challenge). We'll talk about the status of the project to date and expect to have some engaging discussions on some of the implementation choices that we've already made as well as those that are ahead of us still...

(Session proposed by paul luse)


Thursday May 15, 2014 5:00pm - 5:40pm
B302
 
Friday, May 16
 

9:00am

NFS and its role within Cinder
There are a number of filesystem-based drivers appearing in Cinder, with several using NFS. Shared filesystems are a powerful way to implement block storage but they present some unique challenges. I'd like to talk about the advantages and disadvantages, and to what degree Cinder can/should deal with them.

I can also present how NFS is involved with Manila, and where there is overlap and where there is not.

This session isn't about proposing any new ideas -- it's more about education and discussion. Also this session could be condensed down or combined.

(Session proposed by Ben Swartzlander)


Friday May 16, 2014 9:00am - 9:40am
B305

9:00am

Continuous publishing and automation for Docs
Let's discuss:
- difficulties with old files still being available through Google searches
- web output design three years old
- as more translations become available, making the navigation easier for multiple languages

(Session proposed by Anne Gentle)


Friday May 16, 2014 9:00am - 9:40am
B301

9:00am

Review Horizon Usability Test feedback, proposals
During a few weeks in March, a team of UX designers, researchers, and developers ran and participated in 6 Usability Tests where users were asked to perform basic self-service tasks within the Horizon UI. We got a lot of great feedback from these users and have prioritized an improvements list that would help users get through these tasks much faster and easier in the future.

In this session we will discuss the top findings as well as potential design solutions to these findings.

Blueprints and designs will begin to be discussed before this session so that everyone who attends can have some background and add to the conversation as they wish.

(Session proposed by Liz Blanchard)


Friday May 16, 2014 9:00am - 9:40am
B306

9:00am

Vmwareapi driver roadmap for Juno
A session to discuss changes and improvements to the Nova vmwareapi driver for Juno

(Session proposed by Tracy Jones)


Friday May 16, 2014 9:00am - 9:40am
B303

9:00am

Ops Meetup: Enterprise Gaps
In this session, we’ll work to identify enterprise gaps, such as:
  •    user/group/roles
  •    improving VM availability
  •    service reporting
  •    identity lifecycle management
  •    backup/restore/snapshot/replicate
  •    capacity planning
The Ops Meetup, organized by the User Committee, is a new track comprised of collaborative, working sessions for people who are operating OpenStack clouds (and contributors who want to hear from them). The purpose is to share knowledge and best practices among cloud operators, as well as provide feedback based on experience running OpenStack. The aim of the feedback is to assist the development community in their planning of future releases, ensuring a wide range of operational scenarios are taken into account when architecting new features.  There will be no formal presentations, and a moderate level of knowledge around running OpenStack is assumed. If you're just starting out, the Operations Track [http://openstacksummitmay2014atlanta.sched.org/overview/type/operations] will be much more friendly!

Friday May 16, 2014 9:00am - 9:40am
B308

9:00am

Next major REST API - v2
This session is about next major Sahara REST API version.

We should discuss the overall approach, exact specification and implementation details.
You can find more info in blueprints attached to this session.

Some important points:

* It should be implements using Pecan[/WSME]
* We should discuss when we could name it stable and deprecate the prev. version

(Session proposed by Sergey Lukjanov)


Friday May 16, 2014 9:00am - 9:40am
B304

9:00am

Swift distributed tracing method and tools
This session will include the following subject(s):

Swift distributed tracing method and tools:

Swift is a large scale distributed object store span thousands of nodes across multiple zones and different regions. End to end performance is critical to success of Swift. Methods and tools that aid in understanding the behavior and reasoning about performance issue are invaluable.

Motivation:
1)For a particular client request X, what is the actual route when it is being served by different services? Is there any difference b/w actual route and expected route even we know the access patterns?
2)What is the performance behavior of the server components and third-party services? Which part is slower than expected?
3)How can we quickly diagnose the problem when it breaks at some points ?

Current Implementation:
1)statsD:
a) Designed for cluster level, not for end to end performance.
b) Can not provide metrics data for a set of specific requests.
c) No relationship between different set of metrics for specific transactions or requests.
2)logging:
a) Not designed for real time analysis
b) Require more efforts to collect and analysis
c) No representation for individual span
d) Message size limitation

Can we provide a real time end to end performance tracing/tracking tool in Swift infrastructure for developers and users to facilitate their analysis in development and operation?

Ideas:
Add WSGI middleware and hooks into swift components to collect trace data
Minor fix the current Swift implementation to allow the path to include complete hops.
Analysis tools of report and visualization


(Session proposed by Edward)

Tools/Methodologies for observing/diagnosing swift:

The first step in observing any system behavior is to use a test harness that will allow you to control/vary the load in various ways, something many tools can do for you. However, most tend to be focused on reporting the overall metrics, and pay little attention to what happens over the duration of the test, which led me to write my own (many or which are opensource or could be), which provide the details necessary to help diagnose problems when they occur.

The intent of this talk is to discuss the tools & testing methodologies I use to stress swift and help track down the root causes when problems occur. One of the problems I've been able to uncover were the fact that 1KB PUTS were actually several times slower than 2KB PUTs and once V2.0 of swiftclient was released I was able to quickly identify
a problem with it that caused ALL PUTs to run twice as slow! It's since been fixed.

I've found problems where object servers were taking over a second and by examining fine-grained disk metrics was able to show the problem was with an intermittent high disk latency that had nothing to do with swift but rather a
controller setting!

Currently I'm in the process investigating 2 different problems in both the proxy and object servers where multi-second hangs are occurring under heavy loads. This is something I can easily demonstrate (if not resolved yet) during this session and perhaps as a group can diagnose what is going on in real-time.


(Session proposed by Mark Seger)


Friday May 16, 2014 9:00am - 9:40am
B302

9:50am

Adding Consistency Group support to Cinder
Consistency group is needed for snapshots, backups, remote replication, etc. I'd like to start a discussion on this topic. See the following link for details:
https://etherpad.openstack.org/p/juno-cinder-consistency-groups

(Session proposed by Xing Yang)


Friday May 16, 2014 9:50am - 10:30am
B305

9:50am

Dashboard Accessibility
This session will include the following subject(s):

Dashboard Accessibility:

The dashboard is not currently accessible. Discuss known issues including: lack of wai-aria tagging, underlying widgets aren't accessible, keyboard navigation problems, visualizations/drag/drop interaction that have no alternative, and focus presentation. Plan for what tools should be used for testing, develop a checklist for reviewers, and identify dependencies on outside components that need to be fixed.

(Session proposed by Doug Fish)

Better Overview Pages in Horizon:

Openstack users have expressed the desire to be able to better understand how their cloud resources are being utilized and want the ability to use that data to plan for the future. Cloud Admins need the ability to see how resources are being used across the entire cloud and drill into specific areas that need to be investigated. Cloud Users need the ability to see how resources are being used inside projects they belong to. As OpenStack matures and a monitoring solution is available this would also be a logical integration point where you could reflect any alerts that may be enabled.

Several concepts have been put together to demonstrate different ways to accomplish this request.

http://tvpnk4.axshare.com/#p=admin_overview
http://tvpnk4.axshare.com/#p=admin_overview_-_text
http://tvpnk4.axshare.com/#p=user_overview
http://tvpnk4.axshare.com/#p=user_overview_-_text
http://people.redhat.com/~lsurette/OpenStack/Horizon%20Admin%20Overview%20Pages_2.0.pdf
http://people.redhat.com/~lsurette/OpenStack/Horizon%20Overview%20Pages_v1.0.pdf


The goal of this session would be to share the proposals with a wider audience and align on the overall direction.


(Session proposed by Jeremy Hopkins)


Friday May 16, 2014 9:50am - 10:30am
B306

9:50am

Replace Launchpad OpenID authentication
This session will include the following subject(s):

Replace Launchpad OpenID authentication:

In the Icehouse release cycle we implented the openstackid project that delivers an OpenID authentication mechanism based on openstack.org membership data. The initial plan was to replace Launchpad OpenID with this solution so it can affect all related sites including Gerrit and other infrastructure components. The community portal is a pilot for openstackid integration, and I want to share our experiences. We also identified some areas where we need to improve the solution if we want to deliver a proper user experience for developers and end-users.

Let's discuss the future of the authentication, common registration and profile management of openstack.org related services.

(Session proposed by Marton Kiss)

Introduction to OpenStack OpenID Provider:

Describe the new OpenID provider developed by OpenStack Foundation and start laying out the roadmap to ditch Launchpad as default OpenID provider.

(Session proposed by Stefano Maffulli)


Friday May 16, 2014 9:50am - 10:30am
B301

9:50am

Docker driver - features & testing
Icehouse saw Docker moved from Nova into Stackforge. Efforts are underway to gate the Docker virt driver against Tempest and to close the feature gap against Nova's other virtualization drivers.

We'll discuss the current state of affairs and the path forward.

(Session proposed by Eric Windisch)


Friday May 16, 2014 9:50am - 10:30am
B303

9:50am

Ops Meetup: Database
Discussion of what database storage (and non-RDBMS storage) is in use for different endpoints, and how it scales.

The Ops Meetup, organized by the User Committee, is a new track comprised of collaborative, working sessions for people who are operating OpenStack clouds (and contributors who want to hear from them). The purpose is to share knowledge and best practices among cloud operators, as well as provide feedback based on experience running OpenStack. The aim of the feedback is to assist the development community in their planning of future releases, ensuring a wide range of operational scenarios are taken into account when architecting new features.  There will be no formal presentations, and a moderate level of knowledge around running OpenStack is assumed. If you're just starting out, the Operations Track [http://openstacksummitmay2014atlanta.sched.org/overview/type/operations] will be much more friendly!

Friday May 16, 2014 9:50am - 10:30am
B308

9:50am

Sahara in Icehouse and Juno
1) Juno dev cycle Roadmap

We should prepare and discuss our roadmap for the Juno release with approximately assignments and deadlines.

===========================

2) Icehouse dev cycle Retrospective

* What did work well?
* What didn't work well?
* What does need to be improved?

(Session proposed by Sergey Lukjanov)


Friday May 16, 2014 9:50am - 10:30am
B304

9:50am

More Efficient Object Replication
Description:

In this talk, we propose a more efficient way for object replication. The main idea is reducing the amount of data transfer between regions. In this approach, Swift will firstly transfer each replica one time only to the destination region and then fan that replica out in the region locally if the region requires more than one replica.

Background:

We have confirmed in our experiments that the features for geographically distributed clusters will bring great benefits which achieves low latency responses if utilizing high latency networks due to the long distance between regions needed to ensure the possibility of disaster recovery.

However, the current Swift approach manages the limited network between regions wastefully. The current Swift spreads replicas evenly among the destination nodes in the cluster and so unfortunately it allows the sending of the same replica multiple times throughout a single limited network. Generally speaking, the cost of a limited network accounts for a substantial percentage of the total running cost (in our experience, this is greater than 20 %) so we should try to decrease it by using this approach.

(Session proposed by Kota Tsuyuzaki)


Friday May 16, 2014 9:50am - 10:30am
B302

10:30am

Break
Friday May 16, 2014 10:30am - 10:50am
Design Summit area

10:50am

3rd Party Driver Certification / CI Systems
Would like have a session to level-set expectations and timelines around the 3rd party driver certification process going forward.

(Session proposed by Andrew Kerr)


Friday May 16, 2014 10:50am - 11:30am
B305

10:50am

Horizon Dev/Ops Session

Many times we've heard a desire for more feedback and interaction from users. However, their attendance at design summit sessions is met with varied success.

However, last summit, by happy accident, a swift session turned into a something a lot more user driven. A competent user was able to describe their use case, and the developers were able to stage a number of question to them. In this way, some of the assumptions about the way certain things were implemented, and the various priorities of future plans became clearer.

This session proposes to run such an an "ops" session for the horizon project.

Primarily, the purpose of this session is to for developers to ask the operators to answer questions, and request information. However, operators could also be allowed to tell the developers things (give feedback) as a secondary purpose.


https://etherpad.openstack.org/p/ATL-ops-dedicated-design-summit-sessions

(Session proposed by Tom Fifield)


Friday May 16, 2014 10:50am - 11:30am
B306

10:50am

Translation platform discussion
As a continued discussion of last summit, we will discuss:
(1) whether to move away from Transifex
(2) which tool we should select
(3) how to migrate

(Session proposed by Ying Chun Guo)


Friday May 16, 2014 10:50am - 11:30am
B301

10:50am

Neutron Group-based Policy
This session will focus on the Group-based Policy abstractions in Neutron. These abstractions aim to extend Neutron with policy and connectivity constructs that enable significantly more simplified and application-oriented interfaces. There is a dedicated sub-group actively working on this topic. In this session we will recap the definitions of the proposed abstractions, report on the progress made so far, and lay out the short and long term plans for this stream of work.

(Session proposed by Sumit Naiksatam)


Friday May 16, 2014 10:50am - 11:30am
B304

10:50am

Future of Gantt APIs and interfaces
Gantt project (Nova scheduler forklift) is planned to be delivered on Juno cycle. We think that it's time for discussing with all teams in terms of what are the expectations for the future interfaces (APIs), what would be the inputs and outputs, and what kind of objects Gantt would need to store.

(Session proposed by Sylvain Bauza)


Friday May 16, 2014 10:50am - 11:30am
B303

10:50am

Ops Meetup: Issues at Scale
Running a large cloud? Where does it break for you? Come share your story and hear from others.

The Ops Meetup, organized by the User Committee, is a new track comprised of collaborative, working sessions for people who are operating OpenStack clouds (and contributors who want to hear from them). The purpose is to share knowledge and best practices among cloud operators, as well as provide feedback based on experience running OpenStack. The aim of the feedback is to assist the development community in their planning of future releases, ensuring a wide range of operational scenarios are taken into account when architecting new features.  There will be no formal presentations, and a moderate level of knowledge around running OpenStack is assumed. If you're just starting out, the Operations Track [http://openstacksummitmay2014atlanta.sched.org/overview/type/operations] will be much more friendly!

Friday May 16, 2014 10:50am - 11:30am
B308

10:50am

Swift and Python 3 Strategy
I would like to spend some time discussing what our strategy should be for Python 3 and Swift.

(Session proposed by creiht)


Friday May 16, 2014 10:50am - 11:30am
B302

11:40am

Changed block list between volume snapshots
Currently Cinder supports snapshot and backup APIs. But these are not enough to implement incremental backups for Cinder volumes. The backup API backups up the entire volume when a backup is performed. Though it performs compression, it still requires to read the entire volume and upload the data to swift. In order to support incremental backups, I would like to propose a new API that returns list of blocks that are changed between two snapshots. Lets assume a Volume v1 has a point in time snapshots s1 and s2 that are taken at t1 and t2 respectively. The changed block api takes s1 and s2 as arguments and returns the list of changed blocks between s1 and s2. These changed blocks are read from S2. This will satisfy the incremental backup scenario. The backup software may perform incremental backups with respect to full backup or with respect to last incremental backup and hence the changed block API need to support changed block list between any two snapshots.

The changed blocks or the delta is represented as QCOW2 file with reference to s1 as the backing file.

(Session proposed by Murali Balcha)


Friday May 16, 2014 11:40am - 12:20pm
B305

11:40am

Beef Up User and Operations Guides for Integrated
As an example, short-comings have been identified in the currently available Ceilometer documentation, especially in the aspect of being too developer-focused, at the expense of the content is explicitly aimed to help new users and experienced cloud operators.

The User Guide of this component should contain a Quick Start/Getting Started guide, which is currently missing from Ceilometer's documentation base. One potential first step for filling this gap is to reuse the existing Ceilometer Getting Started Guide for RDO and present it in a distro-agnostic form.

The other incomplete part of the current documentation is the outdated section in the Operations Guide under OpenStack Manuals: http://docs.openstack.org/trunk/openstack-ops/content/logging_monitoring.html . Based on the outcome of the Dev/Ops session proposed for Ceilometer, the Telemetry related section can be extended with the requested information.

The goal of this session is to identify the uncovered/incomplete areas in the existing documentation and proposing ways for filling the gaps and improving the already existing parts.

(Session proposed by Ildiko Vancsa)


Friday May 16, 2014 11:40am - 12:20pm
B301

11:40am

User & Group IDs
https://etherpad.openstack.org/p/juno-keystone-user-ids

This session will include the following subject(s):

Identity Providers:

LDAP, SAML, and The SQL Identity Backend all have assumptions about how IDs should be allocated. This session will discuss how to ensure they can interoperate in a single Keystone instance.

(Session proposed by Adam Young)

Identity IDs in a multi-backend or Federated world:

Today, our SQL and LDAP backends can produce very different formats for ID (e.g. 32 char UUID for SQL, while some arbitrary 64 char string for LDAP). In addition we have the requirement to enable keystone to route an API call with just an entity ID as a parameter to the relevant backend serving it (for example when we have an LDAP per domain). We discussed two solutions during the IceHouse development (a mapping table or encoding the domain into the Identity ID - both we coded, but in the end decided to wait to allow more discussion). Some other folks would like keystone to essentially hide the real format of the identifier behind a "as small as possible" ID for efficiency and security point of view. Time to plot our course for Juno!

(Session proposed by Henry Nash)


Friday May 16, 2014 11:40am - 12:20pm
B306

11:40am

Combined FWaaS and VPNaaS Discussion
One of the main issues we hope to cover here and close on is secure key management.

This session will include the following subject(s):

Neutron VPNaaS in Juno:

This is a combined session for VPNaaS in Juno.
Topic is including followings and more.

Discussion topic
- Discussion for secure store for key management
- Flavor framework support
- Service Insertion/ Group based policy support

Techs
- SSL-VPN
- L3VPN (BGP/MPLS)
- IPSec/L2TP
- IPSec/Certificate support

Vendor Plugins
- Cisco, NSX


(Session proposed by Nachi Ueno)

Neutron Firewall as a Service (FWaaS):

This session is a status update on the work accomplished by the Firewall as a Service Neutron sub-group during the Icehouse release. We will also discuss the short and long term plans including revisiting existing roadmap, and any new requirements introduced by vendor drivers.

(Session proposed by Sumit Naiksatam)


Friday May 16, 2014 11:40am - 12:20pm
B304

11:40am

Common no DB Scheduler
We have duplication of code in: Cinder, Nova and in future as well in Neutron.

They all use Scheduler to chose where resource could be obtained. Current algorithm is next:

All resources reports they status to DB
Scheduler on each request Fetch All DB records => make decision where to obtain resource => send request

In big deployments we have a lot of recourse that are attacking DB, and scheduler that is fetching big amounts of date from DB => produce bottleneck (that cannot be fixed by adding more DB servers).

Another problem that we have is that cross-project scheduling is impossible. E.g. If you would like to schedule instance on host that has enough disk space. (Nova & Cinder scheduler data)


But fortunately there is the another approach, that doesn't requires too much changes in current arch to cover both things.


Intro:
Actually almost almost everything is already done:

Schedulers are separated services, only thing that produce problem is that they are heavy bind to data from DB of project, and that they use DB of project.

To resolve this we can make next steps:
1) Each resource sends updates to scheduler (instead project DB)
2) Scheduler that took this update, sends it to common key-value in memory storage (between all scheduler service). => and using smart algorithm all schedulers updates their state of all resources.
3) Add name space for updates that are sends to scheduler (e.g. cinder/nova/...)
4) Cleanup: All calls to db.api: compute_node and volume_node methods now should work through rpc API of scheduler (and in future should be removed and API of Nova,CInder should directly call Scheduler service)

5) Split new Scheduler from Nova to separated project (now it is simple, cause new repo doesn't change anything)
6) Cinder resources should send updates to new project (Gantt)
7) Copy cinder filters to Gantt
8) Remove old Cinder scheduler and use Gantt

blueprint in Nova:
https://blueprints.launchpad.net/nova/+spec/no-db-scheduler


(Session proposed by Boris)


Friday May 16, 2014 11:40am - 12:20pm
B303

11:40am

Ops Meetup: Meta Discussion – ops communication and governance
Administrative discussion about operator's place in the community, specifically looking at the user committee governance and future events like this one.

The Ops Meetup, organized by the User Committee, is a new track comprised of collaborative, working sessions for people who are operating OpenStack clouds (and contributors who want to hear from them). The purpose is to share knowledge and best practices among cloud operators, as well as provide feedback based on experience running OpenStack. The aim of the feedback is to assist the development community in their planning of future releases, ensuring a wide range of operational scenarios are taken into account when architecting new features.  There will be no formal presentations, and a moderate level of knowledge around running OpenStack is assumed. If you're just starting out, the Operations Track [http://openstacksummitmay2014atlanta.sched.org/overview/type/operations] will be much more friendly!

Friday May 16, 2014 11:40am - 12:20pm
B308

11:40am

Tuskar Direction for Juno
I'd like a session to talk about the direction of Tuskar for Juno. Some base ideas are documented here:

https://wiki.openstack.org/wiki/TripleO/TuskarJunoPlanning

Optimally, we'd delve into these in detail to come closer to a consensus on goals and approach.

(Session proposed by Tzu-Mainn Chen)


Friday May 16, 2014 11:40am - 12:20pm
B302

12:20pm

Lunch
Friday May 16, 2014 12:20pm - 1:20pm
Design Summit area

1:20pm

Cinder state & workflow management
A broad session but would like to gather everyone to talk about the current state of cinder with regards to state and workflow management:

This may involve:

* API's in cinder using taskflow, how to further that development there of taskflow integration to help workflow management (and resumption and such in cinder).
* https://etherpad.openstack.org/p/taskflow-cinder
* When to introduce new API's using taskflow (or refactoring existing ones).
* This will help resolve the questions that came up in icehouse about refactoring new API's to use taskflow, creating new ones...
* How to move toward a defined states model (and when/how this would interact with taskflow and other parts of cinder). Hopefully can get more real traction on this in juno.
* Other

(Session proposed by Joshua Harlow)


Friday May 16, 2014 1:20pm - 2:00pm
B305

1:20pm

Service Catalog
https://etherpad.openstack.org/p/juno-keystone-service-catalog

This session will include the following subject(s):

Create multi-attribute based endpoint groups:

The Multi-Attribute Endpoint Grouping proposal allows endpoints to be grouped accordingly to one or more characteristics. For instance endpoints can be located in different regions, and for this reason it could be beneficial group them using this attribute. At the same time there could be endpoints that are administrative in nature and should be used by admins only regardless of their geographical location. Using this proposal it would be possible to create a USAdmin, EuropeAdmin and AsiaAdmin groups to include all the endpoints that follow the above mentioned characteristics.

(Session proposed by Fabio Giannetti)

Discoverable and Hierarchical Catalog:

The current Keystone catalog does not have a coherent design to address a typical IT catalog stack. The lack of data organization and self-discovery approach makes it very limited in use and does not provide a good solution for a global service catalog that can support IaaS, PaaS and SaaS.

Our approach is to change the catalog definition to make it easy to discover the services, their geographical location, type and access interfaces.
The proposed solution is to create a catalog that is built on a hierarchical structure.

The tree-like structure can be then navigated using a set of links that provides URL pointing to the next level in the hierarchy something like, child/parent relationship.

(Session proposed by Fabio Giannetti)


Friday May 16, 2014 1:20pm - 2:00pm
B306

1:20pm

LBaaS - advanced capabilities SSL L7 rules
This session will include the following subject(s):

LBaaS - advanced capabilities SSL L7 rules:

Discuss SSL and L7 features for Juno


(Session proposed by Samuel Bercovici)

LBaaS - advanced and automated scenarios support:

How can the following use cases be supported and what is needed from LBaaS?
1. Autohealing - detect that an application node has failed and replace it including the load balancing configuration
2. Application Maintenance - take off a member for maintenance without loosing active customers
3. Scale-out/scale-in - adding and removing application mambers on demand using KPI breaches.

Discuss metrics and alters needed from LBaaS
Discuss where to consume the metrics and alerts



(Session proposed by Samuel Bercovici)


Friday May 16, 2014 1:20pm - 2:00pm
B304

1:20pm

Simultaneous Scheduling for Server Groups
The server group concept (introduced in https://blueprints.launchpad.net/nova/+spec/instance-group-api-extension) has an API that implies sequential scheduling --- the group members are scheduled as they are created rather than all at once. The next step to take on the road to holistic scheduling is to enable simultaneous scheduling for today's server group concept.

(Session proposed by Mike Spreitzer)


Friday May 16, 2014 1:20pm - 2:00pm
B303

1:20pm

Ops Meetup: Ansible
What are you using Ansible for?
What is missing from Ansible for OpenStack?
Why aren't you using Ansible?

The Ops Meetup, organized by the User Committee, is a new track comprised of collaborative, working sessions for people who are operating OpenStack clouds (and contributors who want to hear from them). The purpose is to share knowledge and best practices among cloud operators, as well as provide feedback based on experience running OpenStack. The aim of the feedback is to assist the development community in their planning of future releases, ensuring a wide range of operational scenarios are taken into account when architecting new features.  There will be no formal presentations, and a moderate level of knowledge around running OpenStack is assumed. If you're just starting out, the Operations Track [http://openstacksummitmay2014atlanta.sched.org/overview/type/operations] will be much more friendly!

Friday May 16, 2014 1:20pm - 2:00pm
B308

1:20pm

Grenade current status and next steps
Grenade is the upgrade testing framework for OpenStack that runs in
the gate. While it doesn't catch all upgrade issues, it does prevent a
large number of upgrade issues that would slip by otherwise.

In this session we plan to discuss major changes in Grenade that
happened in Icehouse cycle, like partial testing, and a more modular
framework moving foward.

The bulk of the session will look at the things we should do in the
next cycle, and prioritize some of the work, and hopefully recruit new
volunteers. This includes (but may not be limitted to):

* Forward upgrading (nearly done)
* Partial upgrade beyond n-cpu?
* Using grenade outside of the gate (it is often broken, we need a
better model for testing that)
* Documenting Grenade - very few people understand it, would be nice
to change
* Growing grenade contributors. Sean, Dean, Mauro, Joe is a very
small number of folks that understand this enough for the level
that we rely on it.
* Gate job formatting, grenade is still a big ugly dump like devstack
used to be, we should probably change that.
* Enhancing javelin (carry forward more resources)
* How to track TODO / bugs in grenade (we do this very poorly today)


(Session proposed by Sean Dague)


Friday May 16, 2014 1:20pm - 2:00pm
B301

1:20pm

TripleO Development and Testing Environment
There was some initial discussion of this topic on the openstack-dev mailing list a while back, but it may be useful to have some face-to-face talks as well. The issue to be addressed is the hardware requirements for a full HA devtest run. As it stands right now, a full HA devtest run would exhaust the resources of a 16 GB system, which is what many TripleO developers use.

Possible topics:

-Do we want to allow lighter weight development environments that don't exercise the full functionality of a standard HA TripleO deployment.
-If so, what do those environments look like?
-Alternative development environments that would allow spreading the load over multiple machines. For example, distributed libvirt VMs or running devtest against OpenStack instances on a public cloud.
-Depending on which direction is chosen, what needs to happen to enable use of that environment?

There are some more detailed ideas in the spec for the linked blueprint.

(Session proposed by Ben Nemec)


Friday May 16, 2014 1:20pm - 2:00pm
B302

2:10pm

Framework for detailed volume statistics reporting
For cloud deployers who are using different storage back-ends (potentially) from different vendors, which can be usual for private clouds transformed from traditional enterprise IT environment, it'd be great if there is a unified mechanism to collect Cinder level volume statistics on a per volume basis.

Some of options for Cinder to provide such reporting/monitoring capability:
1) Sends volume statistics to Celiometer via notification using uniform format; deployer's monitoring infrastructure can then consume those information from Celiometer;
2) Extend Cinder API with an admin-only statistics query extension to allow that information be queried directly from Cinder API;
3) Do both 1) and 2).

In this session, I'd like to discuss these implementation options. Also would like to discuss with back-end vendors about Cinder internal APIs definition for collecting statistics from storage.

(Session proposed by Huang Zhiteng)


Friday May 16, 2014 2:10pm - 2:50pm
B305

2:10pm

Heiarchical Network Topologies
This session is a combination session around common ideas in network topologies.

This session will include the following subject(s):

Support for VDP in Neutron for Network Overlays:

This is for topologies where Openstack compute nodes are connected to the external switches or fabrics. The fabric comprising of the switches support more than 4K segments. In some of these architectures network based overlay (and not host based overlay) is deployed. So, one should be able to create more than 4K networks in Openstack. One way in which the VLAN to be used for communication with the switches is assigned by the switches using 802.1QBG (VDP) protocol. The VM's then sends .1q frames to the switches and the switches associate it to the segment (VNI in case of VXLAN).
With the current model:
1. One cannot use a type driver of VLAN because of the 4K limitation. Also a type driver of VXLAN or GRE cannot be used because that may mean host based overlay.
2. Also the programming of flows should be done after communicating the vNIC information to VDP and VDP communicates with the leaf switches and return the VLAN to be used by this VM. The Openstack module running in the compute communicate with VDP module (Opensource lldpad) running there. The VLAN is of local significance between the compute node and the switch to which it is connected.

Please refer the specification link in the blue print for some detailed information. This can be used in any Network based Overlays with either top down or bottom up VLAN assignment:
a. In VDP based VLAN assignment (bottom-up) , changes in the OVS Neutron Agent code to communicate with VDP and get the VLAN for programming the flows.
b. In Top down model, the controller knows the VLAN to be used by the VM. It can pass that information to the Neutron agent for programming the flows.

A configuration parameter is required that specifies whether the network overlay uses VDP based mechanism to get the VLAN. Something like below:
802_1_QBG_VDP=True/False

(Session proposed by Pradeep Krish)

physical network topology api:

Neutron extension for physical network topology.
This extension allows plugin/mechanism driver to utilize those information
about underlying networks in order to make better use of network resources.

(Session proposed by Isaku Yamahata)

Dynamic Network Segments in ML2:

This session addresses changes needed to ML2 to enable dynamically managed network segments connecting hypervisor vswitches to upstream switches that provide network fabric tunnels/overlays/etc.. The goal is to allow segments such as VLANs to be allocated separately for each switch so that the 4K VLAN limit no longer imposes a global limit on the number of virtual networks. This is similar to the way in which local VLAN tags are managed within br-int by openvswitch-agent.

The session is related to two other proposed sessions. One, http://summit.openstack.org/cfp/details/314, covers support for VDP, which is one way of dynamically managing hypervisor to switch segments. The other, http://summit.openstack.org/cfp/details/93, covers physical network topology, which would be useful in implementations where the ML2 mechanism driver itself dynamically manages hypervisor to switch segments.

(Session proposed by Robert Kukura)


Friday May 16, 2014 2:10pm - 2:50pm
B304

2:10pm

Scheduler hints for VM life cycle
When creating VMs with scheduler hints, scheduler hints will only take effect at deploying time. After the VM was deployed, scheduler hints will be lost.

Later on when someone try to migrate the VM, this VM can be migrated to a host which might violated the original scheduler hints. Same problems also exist for resize, cold migration etc.

A proposed solution was store scheduler hints so that it can be available for the whole life cycle of the VM instance, this can make sure the VM can retrieve and evaluate the scheduler hints before doing some VM operations so as to make sure the VM will always obey its scheduler hints during its life cycle.

A problem was where to store the scheduler hints, add a new filed in instances table or just store in system metadata (is metadata big enough to store large scheduler hints)?

(Session proposed by Jay Lau)


Friday May 16, 2014 2:10pm - 2:50pm
B303

2:10pm

Ops Meetup: Chef
Those of us using Chef - let's chat!

The Ops Meetup, organized by the User Committee, is a new track comprised of collaborative, working sessions for people who are operating OpenStack clouds (and contributors who want to hear from them). The purpose is to share knowledge and best practices among cloud operators, as well as provide feedback based on experience running OpenStack. The aim of the feedback is to assist the development community in their planning of future releases, ensuring a wide range of operational scenarios are taken into account when architecting new features.  There will be no formal presentations, and a moderate level of knowledge around running OpenStack is assumed. If you're just starting out, the Operations Track [http://openstacksummitmay2014atlanta.sched.org/overview/type/operations] will be much more friendly!

Friday May 16, 2014 2:10pm - 2:50pm
B308

2:10pm

oslo.rootwrap: performance and other improvements
As of Icehouse, oslo.rootwrap is released as a separate library, to be consumed by entry points defined in various OpenStack components. However it's far from addressing all the known issues.

The main issue is performance, especially in call-heavy consumers like Neutron. Various options were discussed on the ML, let's see what we want to do about it within the Juno cycle.

Other persistent issues are mostly linked to improving filter definitions in consuming projects to actually make rootwrap useful as a security device. We'll run through those and define easy targets (again).

(Session proposed by Thierry Carrez)


Friday May 16, 2014 2:10pm - 2:50pm
B306

2:10pm

QA Program Policy and Changes in Juno
A lot has changed in the QA community since the start of the Icehouse cycle. This session will be a discussion of new project policy changes that we need to make for the new development cycle. For example, requiring unit testing on certain classes of commits or work out the exact bp proposal and review process now that we have the qa-specs repo.

(Session proposed by Matthew Treinish)


Friday May 16, 2014 2:10pm - 2:50pm
B301

2:10pm

TripleO and Docker
Discuss ideas about Docker integration with TripleO.

Let's discuss and get some ideas flowing about how this might work. Goals would be about coming up with some high level plans to try vs. actual direction setting. Would like to start making some of the "unknowns" into "knowns" so that when we're ready to define a plan (perhaps for the K release), we'll have better information and footing.

Some discussion points:
* Building Dockerfiles using the tripleo elements. Likely one Dockerfile for each service
- nova-api, nova-conductor, keystone, database, etc...
- elements would likely need to be more flexible, see my other session about some ideas around that (http://summit.openstack.org/cfp/details/312)
* Getting the container host(s) deployed onto baremetal to serve as a nova compute node
- provision via ironic
- ubuntu, fedora/rhel atomic, coreos for the host OS
* Orchestration of the container deployments across the container host(s)
- heat templates with resources per container/application
- use Nova Docker driver to do actual container deployment
- we should help drive the docker driver in Nova to completeness

So, there's 2 deployments there (the container host, and the containers themselves). Can these be done as one deployment via Heat orchestration, or do we have to deploy 2 "clouds"?

Where could we use Docker? Seed and undercloud seem to make sense. What about using Docker for some Overcloud services?

Some additional background:
http://lists.openstack.org/pipermail/openstack-dev/2014-January/023350.html


(Session proposed by James Slagle)


Friday May 16, 2014 2:10pm - 2:50pm
B302

3:00pm

Multiple pools per backend
Currently the cinder scheduler views each backend as a homogenous pool of storage. In reality, storage controllers often have different "pools" of storage with distinct characteristics and capacities, defined either by available hardware or by administrative decisions.

There are some possible workaround for this situation today but they all have huge flaws.

We have prototyped a few approaches to allow a single driver/backend to expose multiple pools to the scheduler with simple extensions to the existing design.

(Session proposed by Ben Swartzlander)


Friday May 16, 2014 3:00pm - 3:40pm
B305

3:00pm

L3 Vendor plugins
There are several potential topics to discuss regarding vendor plugins for L3, such as:

- How to handle vendor specific validation (e.g. say a vendor has restrictions or added capabilities compared to the reference drivers for attributes). Maybe provide a validate/commit/apply override for actions similar to L2 plugin pre/postcommit?
- Providing neutron client with info on vendor capabilities (e.g. should help and validation be extended to include vendor capabilities or should it be delegated to server reporting?)
- Handling and reporting of device driver errors to the user (e.g. failure establishing a IPSec tunnel?) Maybe include a "last action results" field in database that can appear in show command?
- Provider selection for resources (e.g. should VPN IPSec policies have vendor specific policies or should we rely on checks at connection creation for policy compatibility?)
- Handling of multiple device drivers per vendor (e.g. have service driver determine which device driver to send RPC requests, or have agent determine what driver requests should go to - say based on the router type)

The goal would be to come up with schemes that could be used across different vendors and, if possible/sensible, across service types, and would apply for all implementations (including reference).


(Session proposed by Paul Michali)


Friday May 16, 2014 3:00pm - 3:40pm
B304

3:00pm

Nova Dev/Ops Session
Many times we've heard a desire for more feedback and interaction from users. However, their attendance at design summit sessions is met with varied success.

However, last summit, by happy accident, a swift session turned into a something a lot more user driven. A competent user was able to describe their use case, and the developers were able to stage a number of question to them. In this way, some of the assumptions about the way certain things were implemented, and the various priorities of future plans became clearer.

This session proposes to run such an an "ops" session for the Nova project.

Primarily, the purpose of this session is to for developers to ask the operators to answer questions, and request information. However, operators could also be allowed to tell the developers things (give feedback) as a secondary purpose.


https://etherpad.openstack.org/p/ATL-ops-dedicated-design-summit-sessions

(Session proposed by Matt Van Winkle)


Friday May 16, 2014 3:00pm - 3:40pm
B303

3:00pm

Ops Meetup: Puppet
Those of us using Puppet - let's chat!

The Ops Meetup, organized by the User Committee, is a new track comprised of collaborative, working sessions for people who are operating OpenStack clouds (and contributors who want to hear from them). The purpose is to share knowledge and best practices among cloud operators, as well as provide feedback based on experience running OpenStack. The aim of the feedback is to assist the development community in their planning of future releases, ensuring a wide range of operational scenarios are taken into account when architecting new features.  There will be no formal presentations, and a moderate level of knowledge around running OpenStack is assumed. If you're just starting out, the Operations Track [http://openstacksummitmay2014atlanta.sched.org/overview/type/operations] will be much more friendly!

Friday May 16, 2014 3:00pm - 3:40pm
B308

3:00pm

Semantic versioning and oslo
Go over semantic versioning, how its being used in oslo and how we can use it better to help alleviate the issues that could (and likely will) be caused by having many new libraries. To avoid breaking core openstack projects with library versions, API changes (or other feature additions/removals) we need to make sure we are all on the same page with regards to versioning.

See: http://semver.org/

(Session proposed by Joshua Harlow)


Friday May 16, 2014 3:00pm - 3:40pm
B306

3:00pm

Juno release schedule and processes
The release management team will discuss the Juno release cycle, as well as improvements to the release process, including:

- Finalization of the Juno release schedule
- New freezes
- New release automation
- Evolutions to the weekly meeting format
- Spreading the release management load around

(Session proposed by Thierry Carrez)


Friday May 16, 2014 3:00pm - 3:40pm
B301

3:00pm

TripleO CI and testing
I anticipate this being more CI than unit testing - but will leave exact timings to Ben and Derek.

This session will include the following subject(s):

Unit testing TripleO and Friends:

TripleO currently has a CI system in place that does a good job of covering the basic devtest workflow, and makes sure changes that break said workflow don't get in. However, it cannot reasonably be expected to cover every possible code path in TripleO and the associated projects. That sort of coverage requires unit testing, which is something that is rather lacking in most of the TripleO projects right now.

This lack of unit testing puts more pressure on reviewers - not only do they need to review for big picture issues, they also have to watch for simple correctness. It's entirely possible for changes to be submitted that just plain don't work. Unit testing would, at least in some cases, alleviate this by allowing them to trivially check that the unit tests cover the changed code, and as long as the gate/check job passes the code is most likely functionally correct.

Some specific topics that could be discussed:
-Additional infrastructure needed to test some parts of TripleO (for example, a fake root environment that would allow testing of scripts that expect to write to system file locations)
-At what point should we start requiring unit tests for new features.
-What, if any, things do we not want to require unit tests for. For example, some incubator scripts might be going away and thus not worth the effort. There also may be configuration scripts that don't make sense when run outside the context of a deployment.
-Methods of testing - Python unit tests, Bash unit testing frameworks, etc.


(Session proposed by Ben Nemec)

TripleO CI :

I like to spend some time talking about
o where tripleo ci should go next
o what our short and medium term priorities should be
o how to best use the resources we have
o dealing with outages

(Session proposed by Derek Higgins)


Friday May 16, 2014 3:00pm - 3:40pm
B302

3:40pm

Break
Friday May 16, 2014 3:40pm - 4:00pm
Design Summit area

4:00pm

What is a Cinder Driver
During Icehouse we received some new submissions for drivers that introduced a new abstraction layer between cinder and 3'rd party devices. These weren't merged, but it brings up an interesting question about what Cinder is and what defines a driver.

Let's take an opportunity to step back and revisit this question and talk about what cinder is and isn't. Particularly what to do with submissions that reimplement components of the service with no concrete object as a backend device. Should these be in tree? Should they be left out as their own Open Source project etc.

(Session proposed by Mike Perez)


Friday May 16, 2014 4:00pm - 4:40pm
B305

4:00pm

DevStack Updates
Current status and future direction for DevStack.

* Structural: continue factoring tasks out of stack.sh into re-usable components (logging, environment setup, etc)
* Testing
* Exercises: retarget back to CLI demo and basic sanity check


(Session proposed by Dean Troyer)


Friday May 16, 2014 4:00pm - 4:40pm
B301

4:00pm

Dynamic Routing for External Connectivity
This session will include the following subject(s):

Dynamic Routing for External Connectivity:

In this session we discuss using dynamic routing protocols to connect OpenStack deployment to external networks

Discussion topics
- Review use cases
(https://wiki.openstack.org/wiki/Neutron/DynamicRoutingUseCases)
- Proposed implementation
- Why start with BGP
- Impact on plugins

Technologies
- BGP

(Session proposed by Artem Dmytrenko)

A More Pluggable External Network:

This session will discuss refactoring the Neutron code around plugging in to an external network. I propose introducing a new interface with multiple implementations to allow using different models to connect Neutron routers to an external network.

These new connection models could help to save public IPv4 addresses that are currently wasted on infrastructure. They could also provide more flexibility to scale networks and float floating IPs more freely.

We will discuss how to transition from the current model to new models in an existing installation.

(Session proposed by Carl Baldwin)


Friday May 16, 2014 4:00pm - 4:40pm
B304

4:00pm

Unsession
We'll use this slot to discuss blueprints or other topics which come up during the nova track.

(Session proposed by Michael Still)


Friday May 16, 2014 4:00pm - 4:40pm
B303

4:00pm

Ops Meetup: Monitoring and Logging
How are you keeping tabs on your cloud?

The Ops Meetup, organized by the User Committee, is a new track comprised of collaborative, working sessions for people who are operating OpenStack clouds (and contributors who want to hear from them). The purpose is to share knowledge and best practices among cloud operators, as well as provide feedback based on experience running OpenStack. The aim of the feedback is to assist the development community in their planning of future releases, ensuring a wide range of operational scenarios are taken into account when architecting new features.  There will be no formal presentations, and a moderate level of knowledge around running OpenStack is assumed. If you're just starting out, the Operations Track [http://openstacksummitmay2014atlanta.sched.org/overview/type/operations] will be much more friendly!

Friday May 16, 2014 4:00pm - 4:40pm
B308

4:00pm

PKI for messaging
Keystone Tokens make use of PKI and the Crytpo Messaging Syntax to sign tokens. If the same mechanism were available in Osl Messaging, writers to a topic could be unmistakably identified, defending against several forms of attacks. The most pressing would be a Hypervisor compromise where malicious data could then be posted to the Schedulers.

In order to use PKI efficiently, each signed message needs to identify which certificate was used to sign it. While the certificate could be embedded in the message itself, that will greatly increase message traffic. Instead, the Messaging infrastructure needs a central registry for Certificate publication. Fetching a certificate from a registry provides no lessening of cryptographic certainty over the message signer's identity, and provides a huge scalability benefit.


(Session proposed by Adam Young)


Friday May 16, 2014 4:00pm - 4:40pm
B306

4:00pm

TripleO Networking
This session will include the following subject(s):

TripleO core network configuration:

Today we currently have a very simple set of bash scripts and elements to configure core networking connectivity (dhcp-all-interfaces, ensure-bridge, init-neutron-ovs, etc). We need need to extend our capabilities with things like support for bonding, better vlan support, static interfaces, provider networks. Basically anything we don't do in neutron directly.

This session is to discuss our approach to a more configurable core networking configuration in TripleO.

-High level config formats (JSON passed in via heat)
-lower level tools which we need (possibly rewritting some of our shell scripts as python tools...)
-look at tools which exist today and outline how we might adopt or learn from these within TripleO

(Session proposed by Dan Prince)

TripleO and Neutron:

Following the http://lists.openstack.org/pipermail/openstack-dev/2014-April/032018.html thread on the ML, we have a few Neutron related questions to discuss:

1. Do we need a separate Neutron node(s)?
2. How do we scale the Neutron node(s)?
3. How do we ensure HA of the Neutron node(s) (neutron-server, l2/dhcp/l3/metadata/lbaas/etc agents)?

Adding Marios' questions here:

4. Subnetting. Right now the undercloud uses a single subnet. Does it
make sense to have multiple subnets here - one point I've heard is for
segregation of your undercloud nodes (i.e.

Friday May 16, 2014 4:00pm - 4:40pm
B302

4:50pm

Glance/Cinder usage of Swift as backing store

Glance can use Swift as backing store in one of two ways:

- Dedicated Glance account. In this mode, all images belonging to all users are stored in a single Swift account. User's do not access the account.

- User's account. In this mode, a user's images are stored in the user's account. When Glance needs to store an image, it creates a containers for the image. Cinder operates in a similar way.

There are usability and consistency problems with the User's account model. From a usability point of view, the user sees oddly named containers when they list their account. The consistency issue is more serious -- the user can delete one of these containers. However, this invalidates Glances's image database -- effectively corrupting it.

The proposed solution is as follows. (Note: the solution is described in Keystone terms, but similar solution could be devised for tempauth).

User accounts are named AUTH_. For example, for tenant/project 1234, the path is /v1/AUTH_1234. It is proposed that Glance use a path such as _ (for example, /v1/GLANCE_1234).

The sequence (and validation steps) to access the GLANCE path is as follows:

- User authenticates in usual way for the 1234 tenant/project. The user now has a token, "token U", scoped to the 1234 tenant/project. The Admin (aka swiftoperator) role is associated with the user for tenant/project 1234.

- Use presents this token in a call to the Glance API. (so far no change to normal process)

- Glance determines that it needs to access the GLANCE_1234 account. It authenticates itself as the "glance" user; not scoped to any particular tenant/project. It gets a token, "token G", with a special role. The role name is something such as "privileged-service"

- Glance performs a Swift request on the /v1/GLANCE_1234 account. The X-Auth-Token header list both "token U" *and* "token G".

- The auth_token middleware validates both tokens -- and combines the roles of both. So now the request has role "Admin" and "privileged-service". In keystoneauth, the "Admin" role is used to allow access to /v1/*_1234 and the "privileged-service" role is used to allow access to /v1/GLANCE_*.

The end user is not aware that the GLANCE_1234 account exists. An attempt to access /v1/GLANCE_1234 will will fail because "Admin" allows access to/v1/AUTH_1234, not /v1/GLANCE_1234.

Similarly, the Glance system credentials by themselves cannot be used to modify /v1/GLANCE_1234 (because the "Admin" role is missing). However, an additional feature that gave the "privileged-service" role read-only access to all GLANCE_* accounts would allow Glance to audit it's database.

A similar scheme can be used by the Cinder service.

(Session proposed by Donagh McCabe)


Friday May 16, 2014 4:50pm - 5:30pm
B305

4:50pm

What should make into devstack
People are often confused of what needs to be inside 'core' devstack and what should live outside.

If things needs to be outside devstack how can we help to extend the external plugin system so the plugins are truly a drop in without having to do any change to the devstack files.

(Session proposed by Chmouel Boudjnah)


Friday May 16, 2014 4:50pm - 5:30pm
B301

4:50pm

Design Summit feedback
In this closing session, we'll reflect back on how this Design Summit went and how we can improve in the future.

"Design Summits" are a key moment in OpenStack development cycles where our development community gathers to brainstorm the next steps for our project, it's critical that we get it right and continuously improve on the format.

We introduced a number of changes this time around (Event staggering, "other projects" track, cross-project workshops, "project pods"...): was that a success ? Should we do them again ?

Friday May 16, 2014 4:50pm - 5:30pm
B306

4:50pm

Neutron Service VM Discussion
This is a combined session. The mailing list discussion around the topic of service VMs being their own project will be discussed here, along with next steps.

This session will include the following subject(s):

Neutron service and devices:

Neutron has gone from a single (core) plugin architecture to one where the (core) plugin is accompanied with a variety of service plugins. The different plugins implement Neutron resources such as network, port, router, firewall, and so on. These resources are realized within different types of network equipment (like ToR switches or firewall boxes) or within regular servers (like in Linux network namespaces or vswitches). More recently, implementation of Neutron resources in Nova-based virtual machines have also emerged as an important use case.

It is not uncommon that a device is capable of implementing multiple Neutron services, e.g., routing, firewall and VPN. When services are provided by separated service plugins this leads to the question: what component manages (the lifecycle of) the devices that the service plugins place resources inside?

Furthermore, a device (not the least a VM) has a limit on how many Neutron resources it can support. So, how is resource allocation in a device done in a deployment with different, concurrently operating service plugins?

The objective of this session is to discuss the above questions and our proposal to handle them: to introduce a device manager service plugin. The task of such a device manager is to manage the life cycle of network devices and monitor their “health” status. The device manager can also be used to police allocation of resources in the devices so to arbitrate between other service plugins. The device manager service plugin is also a natural termination point of REST api for device management.

At Cisco we have developed such a device manager service plugin and as part of the session we can share our experiences from that effort. We also have code that we are willing to share with the community.

This session proposal is closely coupled to the session proposal: Configuration agent for Neutron services.

(Session proposed by Bob Melander)

Configuration agent for Neutron services:

The objective of this session is to discuss the use and benefits of configuration agents to instantiate Neutron resources (like routers or firewalls) in devices.

A configuration agent acts as a delegate for service plugins in configuration and instantiation tasks. This delegation helps to reduce load on the Neutron server. Another suitable task for configuration agents is to monitor the health of the devices it is given responsibility for.

As part of the session we will describe how we have evolved the L3 agent to become a modular configuration agent for (Cisco) devices. This evolved agent is designed to handle multiple services and uses device drivers to support different device types. A configuration task will typically involve pre-propressing and book-keeping steps coupled to a service that are common to all drivers. The configuration agent consolidates that into what we call service helpers. This reduces what need to be implemented in the device drivers.

Each service plugin can use its own RPC to interact with the configuration agent independently of other plugins. The typical plugin - configuration agent workflow involves notifications from service plugin that some resource has been created or updated. The configuration agent then periodically fetches the latest state on such resources. It then apply configurations to reflect the new state.

Another benefit of a joint agent for multiple services is that it can orchestrate the application of configurations so that they are applied in a ordered fashion in a device.
By being a single point of all interactions with a device our configuration agent is also performing health monitoring of devices. As part of that the agent can place temporarily unavailable devices on a backlog. Configuration actions are then deferred until the device becomes available. This has been particularly useful when the device is a Nova-based VM that is created on demand.

This session proposal is closely coupled to the session proposal: Neutron services and devices.


(Session proposed by Hareesh Puthalath)

Advance servicevm framework next steps:

NFV(Network Function Virtualization) support is desired and advanced servicevm framework has been discussed and developed for a while.
As several parties are interested on it,
present the current status to let the people know the various software elements which have been developed and discuss the issues/requirements/related development effort to reach the consensus and define the roadmaps for Juno as next step.


(Session proposed by Isaku Yamahata)


Friday May 16, 2014 4:50pm - 5:30pm
B304

4:50pm

TripleO Dev/Ops Session
Many times we've heard a desire for more feedback and interaction from users. However, their attendance at design summit sessions is met with varied success.

However, last summit, by happy accident, a swift session turned into a something a lot more user driven. A competent user was able to describe their use case, and the developers were able to stage a number of question to them. In this way, some of the assumptions about the way certain things were implemented, and the various priorities of future plans became clearer.

This session proposes to run such an an "ops" session for the TripleO project.

Primarily, the purpose of this session is to for developers to ask the operators to answer questions, and request information. However, operators could also be allowed to tell the developers things (give feedback) as a secondary purpose.


https://etherpad.openstack.org/p/ATL-ops-dedicated-design-summit-sessions

(Session proposed by Tom Fifield)


Friday May 16, 2014 4:50pm - 5:30pm
B302