Loading…
This event has ended. View the official site or create your own event → Check it out
This event has ended. Create your own
Please note: This schedule is for OpenStack Active Technical Contributors participating in the Icehouse Design Summit sessions in Hong Kong. These are working sessions to determine the roadmap of the Icehouse release and make decisions across the project. To see the full OpenStack Summit schedule, including presentations, panels and workshops, go to http://openstacksummitnovember2013.sched.org.
View analytic

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

Tuesday, November 5
 

8:45am

Tuesday Plenaries
The Tuesday plenary sessions.
See http://openstacksummitnovember2013.sched.org/ for details.

Tuesday November 5, 2013 8:45am - 10:45am
AsiaWorld-Summit Hall 2

10:45am

Break
Tuesday November 5, 2013 10:45am - 11:15am
OpenStack Quad

11:15am

DevStack's new bits
Overview of new DevStack features

* revised local configuration (local.conf)
* extras.d hooks for layer 3+ projects
* more?

(Session proposed by Dean Troyer)


Tuesday November 5, 2013 11:15am - 11:55am
AWE Level 2, Room 201B

11:15am

Separate Horizon and OpenStack Dashboard
Horizon is a framework to build UIs using restful services.
OpenStack Dashbaord is just a reference implementation.

I think, we can attract more developers, when promoting horizon unrelated to OpenStack Dashboard.

This session is intended to discuss, what it takes to separate both, does it make sense at all?

(Session proposed by Matthias Runge)


Tuesday November 5, 2013 11:15am - 11:55am
AWE Level 2, Room 201A

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 November 5, 2013 11:15am - 11:55am
AWE Level 2, Room 202

11:15am

Neutron Development Review and Icehouse Policies
This session will include the following subject(s):

Neutron Development Review and Icehouse Policies:

In this session, we will look back on the Havana development cycle and discuss new policy changes for the Icehouse cycle. All plugin and driver contributors are encouraged to have a representative at this session.

(Session proposed by Mark McClain)

CLI: Vendor Specific Command Extensions:

Several vendors have created extensions to support features unique to their plugin. In this session, we'll discuss how to organize the CLI commands to allows users to

(Session proposed by Mark McClain)


Tuesday November 5, 2013 11:15am - 11:55am
AWE Level 2, Room 201C

11:15am

Conductor Tasks Next Steps
Look at tasks as first class citizens in Nova. We can trigger all api actions from the conductor, but leave db read outs in the compute api. Work towards detecting when a worker has died, and reporting or recovering from the error. We can report all the progress and errors through the new Task API that has been proposed.

This work could lead us to a position where we can consider using TaskFlow.

More discussion see:
https://etherpad.openstack.org/IcehouseConductorTasksNextSteps

Its related to the task API session:
http://summit.openstack.org/cfp/details/176

(Session proposed by John Garbutt)


Tuesday November 5, 2013 11:15am - 11:55am
AWE Level 2, Room 204-205

11:15am

Deployment scaling/topologies
This session will include the following subject(s):

Scaling design:

What does scaling mean at the tripleo level; where do we do well, where are lacking, what do we need to design?

(Session proposed by Robert Collins)

Tuskar/TripleO support different architectures:

Justification
-------------
Tuskar should support deploying different architectures of TripleO for the
undercloud and overcloud.

Supporting a flexible deployment architecture allows Tuskar to deploy OpenStack
to meet different goals as needed. In particular, things like:

- different network topologies, such as isolated L2 network domains
- different scaling methodologies to support HA

Description
-----------
Current example deployments of TripleO use an all in one node for the
Undercloud, and an Overcloud with 1 control node and 1 compute node. These are
just the example (and well documented deployments). Tuskar should not tie you
to any one deployment architecture and instead allow for deploying flexible
architectures.

Currently Tuskar assumes that the Undercloud is already deployed, and then uses
the Undercloud services to orchestrate a deployment of the Overcloud.

The flexiblity should apply to both the Undercloud and Overcloud.

Proposal(s)
-----------
1. Define a method so that Tuskar can bootstrap the Undercloud.
- We could start with a seed vm that Tuskar talks to deploy a simple
Undercloud.
- Once the Undercloud is up, reconfigure Tuskar to talk to the Undercloud.
- Proceed with deploying the Overcloud, or scaling out the Undercloud, etc.

2. Define a mechanism for Tuskar to be able to deploy Undercloud nodes after
the seed is removed.
- One such mechanism could be using Heat on the Undercloud to deploy
additional Undercloud nodes (as opposed to just using the Undercloud heat
to deploy the Overcloud).
- The Undercloud may need to scale out new baremetal compute nodes as new
isolated L2 domains are brought online (new rack for instance). Tuskar
should be able to provision these new Undercloud nodes as opposed to a
manual setup process.
- Other resource type nodes should be able to be added to the Undercloud by
Tuskar as well (such as a new network node).
- Configuration changes on the Undercloud should be managed by Tuskar.
Tuskar should be able to use the heat stack-update API to update the
Undercloud (assuming we've used the Undercloud Heat to launch those
nodes).

3. Define a method to deploy different heat stacks (could apply to both
Undercloud and Overcloud).
- Tuskar should have access to a library/repo of different templates for
different node types.
- A Tuskar admin should be able to select different templates (and a
quantity of each) and deploy it as a single stack
- A deployed stack should be able to be "stack updated" by adding additional
templates (or quantities) and updating the stack from Tuskar.


(Session proposed by James Slagle)


Tuesday November 5, 2013 11:15am - 11:55am
AWE Level 2, Room 203

12:05pm

Defining Supported Distros / Projects
One of the big pressures on Devstack is everyone wanting to be included. The laundry list of distros supported is big, and is only prevented in growing by nacking patches for new ones. All kinds of projects want in, and it's still not clear where a project moves to "official enough" to get landed.

All of this means most of what's in devstack isn't tested at all in our CI system (we only run on precise, and only in a small number of configs). That makes the complexity of landing or changing things in devstack, and knowing we didn't break something important, pretty hard.

I'd like to drive some discussion around what it means to be supported. I think requiring distros to be part of the devstack/tempest gate should be required for icehouse, and those that aren't, are either removed or pulled from the documentation. I think for projects and plugins to projects we also need to think about validation requirements. But this should be a lively discussion to try to sort out those boundaries so that we can have an even more solid icehouse version of Devstack.


(Session proposed by Sean Dague)


Tuesday November 5, 2013 12:05pm - 12:45pm
AWE Level 2, Room 201B

12:05pm

Automated Doc Tooling - status & plans
Over the Havana cycle, we pumped up out automation by an order of magnitude. What bits of tooling do we have? Do they work? What do we need? What should we fix?

(Session proposed by Tom Fifield)


Tuesday November 5, 2013 12:05pm - 12:45pm
AWE Level 2, Room 202

12:05pm

Getting Our Heads Around IA
Current information architecture of OpenStack UI is experiencing various issues (horizontal/vertical scaling, usability, etc) and there is common agreement on its improvement.

Thanks to David Lyle's RBAC support [0] which was added to Horizon and there is plan for its extension, we would like to propose new IA to enhance usability and user experience when using OpenStack UI. I would like to have initial proposal for IA enhancements one week before Summit (link should appear in related blueprint).

In this session, I would like to:
* shortly cover current state and explain usability issues,
* introduce initial proposal of IA improvements,
* open discussion and try to find agreement on its future look and regulations when new sections are being added.

[0] https://blueprints.launchpad.net/horizon/+spec/rbac

-- Jarda

(Session proposed by Jaromir Coufal)


Tuesday November 5, 2013 12:05pm - 12:45pm
AWE Level 2, Room 201A

12:05pm

Achieving Parity with Nova-Networking
This session discusses how to close the gap with nova-networking so it can be safely deprecated. Besides feature gaps, this session discusses disparity in testing coverage as well as performance issues, usability and documentation.

(Session proposed by Brent Eagles)


Tuesday November 5, 2013 12:05pm - 12:45pm
AWE Level 2, Room 201C

12:05pm

Instance tasks in API
This session will include the following subject(s):

Instance tasks in API:

As a sort of followup to the instance actions work, and to help facilitate https://blueprints.launchpad.net/nova/+spec/soft-errors I would like to discuss the idea of tasks as their own API resource. This should simplify reporting task failures and allow better tracking of progress. An eventual goal would be the ability to cancel a task.

(Session proposed by Andrew Laski)

feature of Cancel:

In openstack, we should implement the cancel function for the time-consuming API.
For example, Live migration in Nova and Upload to Glance in Cinder and ...
It is useful and kind for user to implement cancel API(or some function) by openstackers.
Here, time-consuming mean what API processing time varies depending on the size of the resource.

(Session proposed by haruka tanizawa)


Tuesday November 5, 2013 12:05pm - 12:45pm
AWE Level 2, Room 204-205

12:05pm

HA/production configuration
This session will include the following subject(s):

HA next steps:

We have working ground-> overcloud now. But it's not HA! Lets get that done.

In particular we need to identify all the things to HA and talk through single node + 2 node + 3+ node setups of them.

(Session proposed by Robert Collins)


Tuesday November 5, 2013 12:05pm - 12:45pm
AWE Level 2, Room 203

12:45pm

Lunch
Tuesday November 5, 2013 12:45pm - 2:00pm
OpenStack Quad

1:20pm

Lightning talks
A Lightning Talk is a short presentation, no longer than 5 minutes. Unlike other presentations at the OpenStack Summit. the lightning talks are unstructured and can be about anything: from code, to running, to any hobby you may have. You can use slides but the 5 minutes need to take into account setting up of your equipment.
You sign up for giving the talk the same day you'll want to deliver it. Participate to the opening sessions every day for more details.
Be creative and have fun.

Tuesday November 5, 2013 1:20pm - 1:50pm
Expo breakout room 1 & 2

2:00pm

Status and future of the restructure
Following from the session at the previous summit[1][2], let's take stock. Assessing how we did in our restructure efforts over Havana, and plan what structural work is needed over the next cycle or two.



[1] http://openstacksummitapril2013.sched.org/event/36ad1110629b6df4f343ce3fd6559587#.Uidekaym3PV
[2] https://etherpad.openstack.org/restructure-docs-session

(Session proposed by Tom Fifield)


Tuesday November 5, 2013 2:00pm - 2:40pm
AWE Level 2, Room 202

2:00pm

Image state consistency between Glance and Nova
When there is a failure in Nova snapshot before uploading the image to Glance (for example failure on hypervisor capturing the disk image as a file) there is no way to notify Glance that this image is in error state nor there is a way to set it to kill. This will result on uncertainty from a client side checking image state, image state will be in queue until the call from Nova to upload which will then go to "saving" and the "active" or "killed" depending on the success of upload to store. If an error occurs before image upload request, nova cannot call update with image to upload and image will stay in "queued" state. Client will not be able to determine if this is a long running snapshot or something bad has happened. So it would be nice if there is a discussion between Glance and Nova folks on the ODS about this.

(Session proposed by Fei Long Wang)


Tuesday November 5, 2013 2:00pm - 2:40pm
AWE Level 2, Room 201A

2:00pm

Neutron VPN-as-a-Service
In this session, we are going to discuss workitems and extension of VPNaaS in Icehouse. We will discuss extending support for MPLS, SSL, and possibly IPSec+L2TP. Additionally, vendor drivers will be covered.


(Session proposed by Nachi Ueno)


Tuesday November 5, 2013 2:00pm - 2:40pm
AWE Level 2, Room 201C

2:00pm

Nova Un-conference (Tuesday)
This session will give an opportunity to cover a variety of topics for 10 minutes each. If you would like to participate, please sign up for a slot on the following etherpad.

https://etherpad.openstack.org/p/NovaIcehouseSummitUnconference

(Session proposed by Russell Bryant)


Tuesday November 5, 2013 2:00pm - 2:40pm
AWE Level 2, Room 204-205

2:00pm

Creating REST services with Pecan/WSME
Now that we have a few projects using Pecan/WSME, let's talk about some best practices and pain points.

Outcomes for this session should include a list of patterns to use, ideas for common code to be added to an oslo library, and ideas for fixes or enhancements in Pecan and WSME.

https://etherpad.openstack.org/icehouse-oslo-pecan-wsme-tips

(Session proposed by Doug Hellmann)


Tuesday November 5, 2013 2:00pm - 2:40pm
AWE Level 2, Room 201B

2:00pm

stable branch support and updates futures
This session will include the following subject(s):

Image based updates:

Updating what we've deployed is a Good Idea. https://etherpad.openstack.org/tripleo-image-updates

(Session proposed by Robert Collins)

Stable branch for tripleo:

TripleO is currently focused on Continuous Delivery from master branches, we may also have a set of users who want to deploy using openstack's stable branches, I'd like to discuss if this something we would like to accommodate and how best can we could do it?


(Session proposed by Derek Higgins)


Tuesday November 5, 2013 2:00pm - 2:40pm
AWE Level 2, Room 203

2:50pm

Documenting Application Developer Resources
Co-presented by Everett Toews and Tom Fifield

The purpose of this session is to outline a vision, and attempt to define the practical steps that we should take over the next year to achieve it.

The Portal
Can you imagine if we had developer.openstack.org?

A single place where application developers coding in any language could come to learn about openstack and find the resources they need to write scalable cloud applications for OpenStack.

The site would be a portal containing links to other areas:
* All of the SDKs
* CLI docs for scripting e.g. in bash
* API documentation (acknowledging that the majority of developers will use SDKs, not the API directly)
* Where to get help

Existing Python Libraries
Answer the question: are python-*client to be treated as libraries? As in: the Python SDK for OpenStack.
If so, an important parallel of this work would be to asess the current python binding resources and improve them to be an exemplar for other SDKs to follow.

What defines an SDK?
From the wiki (https://wiki.openstack.org/wiki/SDKs):
* A set of language bindings that provide a language-level API for accessing OpenStack in a manner consistent with language standards.
* A Getting Started document that shows how to use the API to access OpenStack powered clouds.
* Detailed API reference documentation.
* Tested sample code that you can use as a "starter kit" for your own OpenStack applications.
* SDKs treat OpenStack as a blackbox and only interact with the REST/HTTP API.
* License must be compatible with Apache License v2.

If an SDK does not meet these criteria, it's not considered an SDK for OpenStack.

Additional criteria could be discussed, such as:
* Does the SDK have an active community?
* Is it promptly updated for new API releases?

Join us to discuss these topics as we refine our vision.


(Session proposed by Everett Toews)


Tuesday November 5, 2013 2:50pm - 3:30pm
AWE Level 2, Room 202

2:50pm

What should happen to the v1 images api?
With the v2 api gaining maturity and ready to take center stage, what should we do about the v1 api? Deprecate it in Icehouse? Or keep it for longer, but refactor it so that we don't have to keep duplicating every feature in effectively two different codebases?

(Session proposed by Mark Washenberger)


Tuesday November 5, 2013 2:50pm - 3:30pm
AWE Level 2, Room 201A

2:50pm

Neutron Firewall as a Service (FWaaS)
The FWaaS feature was introduced in the H release with basic functionality. There are a number of complementary/advanced features and work items which were either planned earlier and/or have evolved from the experience after using this initial version. We will discuss these topics during this session.


(Session proposed by Sumit Naiksatam)


Tuesday November 5, 2013 2:50pm - 3:30pm
AWE Level 2, Room 201C

2:50pm

Nova live-snapshot feature
Overview:
Work was done during the Havana development cycle to implement "live-snapshot" for virtual machines in Nova. A live-snapshot is basically a more complete snapshot of an instance. In addition to its disk(s), the memory and processor state is also snapshotted. This allows for a quick launch of an instance from the snapshot instead of the regular cold-boot from a snapshot image.

As it turns out, there were some concerns with the hypervisor support for this feature and it did not make it in for the Havana release. This design session is to revive the feature to determine which hypervisors will support it as well as discuss the concerns over the current Libvirt/KVM implementation.

There are also a few other question that should be hashed out for this feature:
[a] How are we going to handled attached volumes? How do we handle booting with a different set, or different ordering, of volumes?

[b] How are networks going to be affected? Can a live-snapshot be booted with a different set of networks?

[c] Changes in flavours when a live-snapshot is booted -- We have a live-snapshot of an instance with 512MB of memory, but trying to boot a 1GB instance.

[d] Can CPUID heterogenous clouds be supported? How about cloud composed of different hypervisor versions? Any other host-level issues with live-snapshots.

[e] There also appears to be a need for an in-guest agent to help reconfigure the live-snapshot once its booted. How does nova communicate with the agent? When does the agent know to reconfigure the instance and how does it get the information.

(Session proposed by David Scannell)


Tuesday November 5, 2013 2:50pm - 3:30pm
AWE Level 2, Room 204-205

2:50pm

OpenStack Client Update
Review the current status and plan the next steps for OpenStack Client (aka python-openstackclient).

* 0.2 release completed

* testing templates in place, now need to be replicated for each command
* Swift support
* API version detection


(Session proposed by Dean Troyer)


Tuesday November 5, 2013 2:50pm - 3:30pm
AWE Level 2, Room 201B

2:50pm

CI and CD automation
This session will include the following subject(s):

How far do we push devtest.sh?:

devtest.sh has grown in length and complexity from the original devtest.md.

Do we want to keep evolving it until it becomes a defacto standard for bootstrapping a cloud? Where do we draw the lines here?

FWIW I would like to see us continue to decompose devtest.sh into components that will be individually useful to wider audiences, while making it easy for devs to spin up a full environment.

I'd like to get some wider opinions though, since we have multiple semi-intersecting interests here (devs, testing, deployers). If nothing else, the name might want to be revisited if/when toci merges into incubator :)

(Session proposed by Chris Jones)

CI testing:

We need toci in core - so we have scaled tests and get checks when nova changes occur etc.
Other things to consider talking about

What jobs should we be running?
When can we expect to be gating merges on CI tests?
What platforms should we target ?
How can we stabilize the reliability.

o Virtualised resources
o what have we got
o how can be best use them.

o Baremetal resources, same questions
o what have we got
o how can be best use them.
o Is there more resources available, where, when ?

We also need to setup a periodic job that updates a set of known working project git hashes which can be feed into any gerrit triggered jobs. So the gerrit commits wont be effected by breakages in unrelated projects.



(Session proposed by Robert Collins)


Tuesday November 5, 2013 2:50pm - 3:30pm
AWE Level 2, Room 203

3:40pm

Publishing translated documentation
Questions to answer:
Where does the slicing tool live?

(Session proposed by Anne Gentle)


Tuesday November 5, 2013 3:40pm - 4:20pm
AWE Level 2, Room 202

3:40pm

Enhance v2 Image Sharing
Image sharing v2 was released in Grizzly. It provides a basic infrastructure for users (image consumers) to boot from images owned by other tenants (image producers). We'd like to discuss some enhancements to the feature that would support development of an image marketplace. Any such marketplace would be another service -- Glance is not in the business of maintaining user relationships, for instance -- we just want Glance image sharing to provide enough support (not too much, though!) for such a service to be built.

Etherpad for discussion: https://etherpad.openstack.org/enhancing-glance-image-sharing

BP: https://blueprints.launchpad.net/glance/+spec/enhance-v2-image-sharing

(Session proposed by Brian Rosmaita)


Tuesday November 5, 2013 3:40pm - 4:20pm
AWE Level 2, Room 201A

3:40pm

Neutron API Framework Replacement
This session will include the following subject(s):

Neutron Plugin Interface:

The current Neutron plugin interface has accumulated lots of layers and mixins. This session will explore a proposed v3 API interface and the migration path for plugins currently supporting the v2 plugin API.

(Session proposed by Mark McClain)

Neutron API Framework Replacement:

This session will explore the steps necessary to replace Neutron's home grown API framework with the Pecan WSGI Framework. Pecan is used by Ceilometer and Cinder.

(Session proposed by Mark McClain)


Tuesday November 5, 2013 3:40pm - 4:20pm
AWE Level 2, Room 201C

3:40pm

Improve VM boot times, by pre-starting VMs
Windows VMs take a while to boot due to sysprep, and sometimes need to complete installs of things like SQL Server.

You can pick a selection of popular image/flavor combinations that are going to be more quickly available.

We can start up the VM, do steps to make the VM unique (sysprep, etc), then stop the VM (note its not owned by a tenant) then personalize the image as required on the following boot of the VM, transfering the IP and other resources to the appropriate user.

This means the scheduler could first look for a pre-started VM, then look for an empty host, if there are no pre-started VM that could be taken.

A service outside of nova can monitor the current level to pre-started VMs, and start more as needed. Notifications can be sent when each pre-started VM is claimed, so it can be used to trigger the starting of new VMs.

(Session proposed by John Garbutt)


Tuesday November 5, 2013 3:40pm - 4:20pm
AWE Level 2, Room 204-205

3:40pm

Updates to hacking, our code style enforcement tool
This session will include the following subject(s):

Unittests for openstack-dev/hacking:

The tests coverage of openstack-dev/hacking is very poor since docstring tests cannot cover all cases of violation. Lets have a chat about how we could write unittests for it.

(Session proposed by Zhongyue Luo)

Review and prune hacking rules:

We've had a full cycle of enforcement of the hacking guidelines now. While that's wonderful, it has become evident that some of them, like "use except Exception: not just except:" are either nonsensicle OR - do make sense but we do not have good verbage describing why.

I think we probably want to drop some of them from the guide and from enforcement, and additionally we should potentially think about adding MAY and MUST wording to hacking, so that we can include some informational best practices that we never attempt to enforce.

(Session proposed by Monty Taylor)


Tuesday November 5, 2013 3:40pm - 4:20pm
AWE Level 2, Room 201B

3:40pm

Futures - network/discovery/topology modelling
This session will include the following subject(s):

TipleoO, Tuskar: autodiscovery of hardware:

tl;dr: tuskar assumes autodiscovery of physical nodes. Is this trivial,
already done, hard, can't be done? What can we do, how can we help?

Even the earliest versions of the Tuskar UI wireframes/mock-ups assumed
that '(at some point), we'll get a list of available physical hardware
here' even if that means just a list of IP or MAC addresses. The user
story is that after an operator has plugged in a new machine to a
top-of-rack switch (within a tuskar management network), the existence
as well as attributes of that machine are made available to the Tuskar
UI. Operators will not only be able to retrieve hardware information,
but also set constraints and conditions based on the hardware attributes
[1]. All of this implies autodiscovery and enrollment of hardware.

So, what does autodiscovery look like? Is it a brute force:
-1--> Talk directly to the switch and get a mac address - this will at
least let you know that a) machine MAC introduced to switch's MAC-table,
b) you can use that and catch IP assignment (over ARP for example). So
you get MAC and IP.

-2--> ???

-3--> profit


Discussion points:

* How do we find out about the other attributes we're interested in -
cpu, number of phy. cores, memory gbytes, etc etc.

* Is this really obvious as in are there already tools that do this for
us? Can IPMI do this for us?

* There is an existing Ironic blueprint outlining a solution [2][3], are
there any obvious blockers there?

* Is this pretty much sorted in Ironic/other_tool, in which case we
should just make sure Tuskar can talk to that without issue?

* What can Tuskar devs do to help Ironic/other_tool move this along?

[1]
http://people.redhat.com/~jcoufal/openstack/tuskar/2013-10-16_tuskar_resource_class_creation_wireframes.pdf
[2] https://blueprints.launchpad.net/ironic/+spec/advanced-driver-api
[3] https://blueprints.launchpad.net/ironic/+spec/discovery-ramdisk


thanks! marios

(Session proposed by Marios Andreou)

TripleO for network infrastructure deployment:

Currently TripleO manages the deployment of bare-metal compute infrastructure for an OpenStack "overcloud". However this does not address the deployment of the networking infrastructure (e.g. leaf and spine switches) that provide connectivity for the overcloud. This is difficult to achieve with traditional switches since they are deployed in a non-standard fashion (often varies with vendors). However, the Open Network Install Environment (ONIE, http://onie.github.io/onie/) initiative, currently managed under the auspices of the Open Compute project (http://www.opencompute.org/), is being introduced to bootstrap the install of switch operating systems. This opens up the possibility of leveraging Ironic to switch operating system deployment in a standard way (vendor agnostic). We would like to seed this idea in this session and obtain feedback on the direction. This may also generate switch specific requirements for Ironic.

(Session proposed by Sumit Naiksatam)

Modelling infrastructure in TripleO Tuskar:

A key goal of TripleO Tuskar is to provide infrastructure management for an OpenStack deployment. Part of this is modelling the OpenStack services and hardware. Right now there are two key models in Tuskar, Resource Classes and Racks. Introduced by the new wire frames[1] is the idea of L2 Groups, which are designed to replace Racks.

An L2 Group represents a grouping of nodes that are all present on the same Layer 2 network. This allows Tuskar to represent physical reality without being tied to any specific hardware, like for example a Rack.

We need to decide on whether or not these two concepts are enough to model OpenStack infrastructure? If so what information do they need to contain and what behaviour should they have? Are there other things we need to model? Service Types? Hardware Types? Failure Domains? Generic grouping?

In this session we will explore ideas around TripleO Tuskar infrastructure modelling, assessing the suitability of the current model and look at ways to improve upon it.

The overall aim of the session is to gain a consensus for a sensible infrastructure model for version 1 of TripleO Tuskar.

Discussion points:

Resource Classes
Why are these valuable?
Is 1-many mapping from services to hardware sufficient for v1?
Should we support combined services in single resource classes?
L2Groups
What value does an L2 Group bring to TripleO Tuskar?
Is a model based on a layer 2 network a sensible approach?
If so what information do we need to store and how do we utilize these?
Services
How do we manage different services across OpenStack infrastructure?
Who is responsible for upgrades? Migrating of services? Gracefully shutting down services?
Is this part of a resource class or do we need separate model for this?
Do we even need to support this in v1?
Should we group OpenStack services together to create new ones?
To allow co-location of services for things like Compute and Block Storage performance?
Is this in the scope of V1?
Other Components
Are there scenarios in which the above concepts are not sufficient?
If so are these the edge case?
Do we want to support these scenarios in v1 of TripleO Tuskar?
Should we directly model hardware, Rack, Chassis, Power Supplies and so on?
Should we be more flexible in our modelling approach?
Do we want to offer a more generic approach altogether to modelling infrastructure?
How do we stop this becoming overly complex and difficult to use?
Do we shoot for simplicity (and be more opinionated?)


[1] http://people.redhat.com/~jcoufal/openstack/tuskar/2013-10-16_tuskar_resource_class_creation_wireframes.pdf

(Session proposed by Martyn Taylor)


Tuesday November 5, 2013 3:40pm - 4:20pm
AWE Level 2, Room 203

4:20pm

Break
Tuesday November 5, 2013 4:20pm - 4:40pm
OpenStack Quad

4:40pm

improvement of central agent
It has been discussed to merge the ceilometer hardware agent into the central agent during the last weeks' IRC meetings. But there are still some issues in the current central agent we need to address:

- How to horizontally scale out the central agent?
Currently, there is only one central agent allowed in the ceilometer deployment, otherwise there will be much duplication of the metering/monitoring samples. We need to figure out how to deploy several central agents without such duplication.

We may possibly follow the current alarm partition way, i.e. one dynamically elected master central agent will distribute the resources among all the central agents for them to poll.

One thing to be noticed is that unlike the alarm service which have only 1 type of resource - alarms, central agent will have different types of resources for different pollsters, i.e. glance resources, swift resources, hardware resources, etc. The distribution process must take that into account to avoid distribute the resources to other central agent which is not configured to have the relevant pollsters for that type.

- Do we want to allow the admin to manually configure what resources to be polled in the pipeline configuration file?
Besides getting all the available resources from a 3rd party API endpoint, i.e. glance/swift/neutron API, I think it'd better also allow the admin to manually configure the resources in the pipeline file, by adding a new 'resources' item into the pipeline file, just like what the hardware agent does now. The gives the admin much more flexibility.

(Session proposed by Lianhao Lu)


Tuesday November 5, 2013 4:40pm - 5:20pm
AWE Level 2, Room 203

4:40pm

Enhance image location property
With multiple location feature Glance support an image has more then one backend storage location, it allow Glance using HA approach to retrieve their content from different backend when download API be required by client, and Glance also allow the image consumer access image from backend storage directly via a particular location if administrator allow glance export location metadata out to client.

Currently every image property are all belong to the image but its particular location, it caused some limitations for such useful use cases. For example, a location could has own status, under it Glance can handle location more efficiently such as 'pending_delete' for a particular location. And if we moving 'disk_format' and 'container_format' ('checksum', 'size' will be involved) properties to location level, then it could help Glance support more useful use cases, that means an image Glance owned could have different disk and/or container format, this will allow client side such as Nova consuming image more free.

I consider this change will help Glance future features' implementation also.

I'd like discuss following with team:
1. Make sure what we want to make on image location level. Which property want to add, which one want to move.
My candidate: status, disk_format, container_format, checksum and size.
2. Image location state transition diagram if we want to do it.
3. The influence for the consuming side. Client side related changing.
4. Implementation discussion.

Etherpad for discussion: https://etherpad.openstack.org/enhancing-glance-image-location-property
A related BP: https://blueprints.launchpad.net/glance/+spec/image-location-status


(Session proposed by Zhi Yan Liu)


Tuesday November 5, 2013 4:40pm - 5:20pm
AWE Level 2, Room 201A

4:40pm

Storyboard - Basic concepts and next steps
Storyboard is a Django/Bootstrap-based proof-of-concept replacement for task tracking throughout the OpenStack projects. We currently use Launchpad to track those but we are facing a number of limitations, especially in the blueprints side. Writing our own lets us design a system that is closely integrated with other OpenStack infrastructure bits, and precisely matches our development processes and workflow.

The POC currently only contains basic concepts and features and there is a lot of work to do before we can fully replace Launchpad with it. We need a lot more people working on this if we want it to become a reality soon.

This session will introduce the basic concepts behind StoryBoard, map the road ahead and serve to identify interested contributors.

See https://github.com/openstack-infra/storyboard for more.

(Session proposed by Thierry Carrez)


Tuesday November 5, 2013 4:40pm - 5:20pm
AWE Level 2, Room 202

4:40pm

API Deprecation and Extensions
https://etherpad.openstack.org/p/icehouse-keystone-internal-apis

This topic will cover two topics related to Code Management within Keystone. The first is API Deprecation (Internal API Stabilization as well as V2 and future deprecation paths). The second will be Extension mechanisms [use of stevedore, paste, and alembic].

API Stabilization and Deprecation:
Keystone has seen a large amount of shift in the internal APIs over the course of Havana. From that standpoint, it is important to be able to elegantly deprecate these internal APIs in a controlled manner to better support developers and consumers that implement custom code that hooks into keystone (be it a driver, a plugin, or something totally different). The scope of the deprecation should probably be for a single release (e.g. if the interface was deprecated/moved/changed/etc during the Havana cycle, in Icehouse the "deprecated" warning or stub-compat function would be removed). This session should also touch on the public facing APIs and the deprecation mechanism/choices (see the linked blueprint).

ML topic can be seen here: http://lists.openstack.org/pipermail/openstack-dev/2013-October/016704.html


Extension Mechanisms:
The second part of this session will cover the use of the various tools to pull together Keystone and it's extensions. This will cover the use of stevedore, alembic, paste, etc. This is to make sure we are on the same page for handling extension detection both integrated and out-of-tree development. We will also address what is to become core versus strictly extensions (and how this is determined) and how we determine if an extension should become more than an extension.

(Session proposed by Morgan Fainberg)


Tuesday November 5, 2013 4:40pm - 5:20pm
AWE Level 2, Room 201B

4:40pm

Framework for Advanced Services in VMs
Discuss the requirements for a common framework to enable the deployment of advanced networking services that are implemented in virtual machines. See related etherpad here: https://etherpad.openstack.org/p/NeutronServiceVM


(Session proposed by Greg Regnier)


Tuesday November 5, 2013 4:40pm - 5:20pm
AWE Level 2, Room 201C

4:40pm

Implementing Private clouds on Nova via aggregates
A private cloud in this context is set of compute hosts that a tenant has dedicated access to. The host themselves remain part of the Nova configuration, i.e this is different from bare metal provisioning in that the tenant is not getting access to the Host OS - just a dedicated pool of compute capacity. This gives the tenant guaranteed isolation for their instances, at the premium of paying for a whole host.

The concept was discussed briefly (with a good reception) at the Havana summit, since when it has been evolved into a working prototype based almost exclusively on existing aggregate functionality. (In effect it provides a user facing abstraction to aggregates). Although this looks like a scheduler topic it is mainly about a new layer of aggregate manipulation logic on the API server.

Operations a User can perform:
- Create a Pcloud
- Allocate hosts to a Pcloud (of a specific host-flavor and AZ)
- See hosts and instances in the Pcloud
- Schedule instances to a Pcloud
- Give access to other tenants to schedule to the plcoud
- Change the scheduling parameters (cpu allocation ratio, memory allocation ratio)

Operations an Cloud administrator can perform:
- Define a host flavor
- Mark specific physical hosts as being available as a host-flavor

I want to use this session to describe the approach and get feedback on both the current design and what additional features are required.
I also want to discuss some of the potential race conditions in host allocation, and what might be done to address those, and touch on the
performance aspects of using aggregates for scheduling, and what might be done to improve those.


(Session proposed by Phil Day)


Tuesday November 5, 2013 4:40pm - 5:20pm
AWE Level 2, Room 204-205

5:30pm

Expose hardware sensor (IPMI) data
This session will include the following subject(s):

Expose hardware sensor (IPMI) data:

Ceilometer would like to monitor hardware that can not have a local agent (eg., nova-baremetal and ironic tenants).

Since Ironic already requires the IPMI credentials for the hardware it manages, it seems logical for Ironic to expose a mechanism for polling hardware sensor data via IPMI. This API would then be consumed by Ceilometer (and possibly by other services as well).

Let's get the Ceilometer and Ironic teams together to talk about this!

(Session proposed by Devananda)

Canary monitoring integration:

We wrote and maintain Canary (https://github.com/gridcentric/canary), a tool for monitoring OpenStack physical infrastructure. Given that Ceilometer is now taking on some of those responsibilities, we'd like to contribute code and ideas implemented in Canary into Ceilometer in order to have a single, powerful project for OpenStack monitoring.

This session could serve as both an opportunity to discuss different approaches to physical host monitoring (including specific design decisions that we made that were different from Ceilometer) and flesh out a path for implementing and integrating any relevant ideas from Canary.

(Session proposed by Adin Scannell)


Tuesday November 5, 2013 5:30pm - 6:10pm
AWE Level 2, Room 203

5:30pm

Breaking ground with taskflow and glance
Late in the glance havana cycle there was talk about glance having features which would allow for exports/imports and a taskflow like model to accomplish this inside glance. As taskflow is a library designed for just that kind of purpose it would seem to make sense to discuss how taskflow can be used, its functionality, its plans and align it (if possible) with usage inside glance. This will avoid glance creating its own 'mini-taskflow' and let glance focus on doing image exports/imports well while letting taskflow do task running well (a separation that seems appropriate).

(Session proposed by Joshua Harlow)


Tuesday November 5, 2013 5:30pm - 6:10pm
AWE Level 2, Room 201A

5:30pm

External replications and hooks
We're pretty self contained and other than bugs on launchpad, don't actually use anything on external sites for real purposes.

However, people find integrations with external sites, such as our replication to github, helpful for their daily lives. On the other hand, having things in multiple locations also has the potential to confuse people (like the angry pull request dude) If we ARE going to do things with an external site, we should probably figure out automation for it, because the tasks of doing it are probably quite lame and boring.

Let's talk about what external things all of our projects should be associated with and managed in automated fashion. Current list of things to think about:

- github
- bitbucket
- rtfd
- ohloh
- launchpad
- freshmeat

(Session proposed by Monty Taylor)


Tuesday November 5, 2013 5:30pm - 6:10pm
AWE Level 2, Room 202

5:30pm

Refactoring Assignments
https://etherpad.openstack.org/p/icehouse-assignments

The current Identity API and implementation of role assignments is a mess. I'd like to discuss:

1) A more logical API by extending the GET /role-assignment API into a full set of crud operations with "role-assignment" becoming a first class entity. We would deprecate (but still support for a while the existing GET /user/role/project...style)

2) Implementation of a single assignments table/structure in the backend

3) Removal of cross-identity-manager calls from the assignments manager/driver - i.e. assignment is just a mapper...and shouldn't know how to validate the objects it is mapping between (this will be required for federation). However, is there a security risk for that?

(Session proposed by Henry Nash)


Tuesday November 5, 2013 5:30pm - 6:10pm
AWE Level 2, Room 201B

5:30pm

API Extensions for Drivers
This will be a split session to discuss extensions for drivers.

This session will include the following subject(s):

ML2: How to support driver-specific extensions:

In this topics, how to support driver-specific features will be discussed. Various ML2 mechanism drivers are implemented and proposed, and features provided by them may be different. It is one of good topics how to support such extensions in ML2 plugin/drivers.

It is also important from the point of migrating from monolithic plugin to ML2 driver. In the existing monolithic core plugins, support of extensions are different across plugins and some plugins have plugin-specific extensions. They would like to continue to support their extensions even after migrating ML2 plugin.

If an extension introduces a new resource, service plugin is an option. Is it a direction we have service plugins per extension? Generally speaking it seems not a good idea to me. If an extension add a new attribute to an existing resource, what can we do? Should we allow mechanism drivers to define additional extensions list?

ML2 plugin has several merits (potentially support multiple backend, avoiding code duplication across core plugins, ...), so I believe it is worth discussed.

I am now looking ML2 plugin code and looking for possible ways.

(Session proposed by Akihiro Motoki)

Extensible API: deal with growing services:

Neutron has added 3 new services in addition to LBaaS during Havana cycle: FWaaS, VPNaaS, Metering.
More services to follow (possibly).

All these services are implemented as API extensions at this point, but as amount of features and diversity will grow, it will create a need for 'extensions for extensions'.

We need to decide how/what to make part of Core API and propose a way to extend Core Service API with vendor-specific features

(Session proposed by Eugene Nikanorov)


Tuesday November 5, 2013 5:30pm - 6:10pm
AWE Level 2, Room 201C

5:30pm

Flavor level capabilities
A provider may offer many different types of visualization services, and not all Nova features may be offered by all services, or they may want to limit a feature on some flavors. Currently an api call has to make it all the way down to the driver before it can bubble back up that the driver doesn't support that feature (and is very inefficient). I would like to discuss a way that we could discover this at a higher level.

A first thought would be able to assign a set of available capabilities at the flavor level. I'm also open to discussing other ways that such a feature may be implemented.

(Session proposed by creiht)


Tuesday November 5, 2013 5:30pm - 6:10pm
AWE Level 2, Room 204-205
 
Wednesday, November 6
 

7:45am

Breakfast with the Board
Wednesday November 6, 2013 7:45am - 8:45am
OpenStack Quad

9:00am

Wednesday Plenaries
The Wednesday plenary sessions.
See http://openstacksummitnovember2013.sched.org/ for details.

Wednesday November 6, 2013 9:00am - 10:45am
AsiaWorld-Summit Hall 2

10:45am

Break
Wednesday November 6, 2013 10:45am - 11:15am
OpenStack Quad

11:15am

Big Data processing
This session will include the following subject(s):

Big Data processing:

Large deployments may produce huge volume of stats. To see it graphically you may play with http://docs.openstack.org/developer/ceilometer/install/dbreco.html: if there are 20000 instances and probe happens once a minute we will get 1TB per month. Besides, some of metering is better to be probed more frequently and it will increase amount of stored data. At such scale we need to use BigData technologies and Apache Hadoop is one of them. It can work with all backends from Ceilometer: with SQL and DB2 using Apache Sqoop, with Mongo using Hadoop-Mongo connector and HBase. At this session I will share my team's experience in solving metering problems using HBase and Hadoop.

(Session proposed by Nadya Privalova)

Scaling Ceilometer:

Certain meters need to be able to check and provided data on the health and status of workloads, storage, network, etc. nearer to real-time in order for automated (or manual) notifications to be generated against policies to fix "problems" as they occur. Currently, Ceilometer defaults to collect meters at 10minute intervals but it is foreseeable that there are meters that need to be captured at a much finer granularity (in the milliseconds). Additionally, Ceilometer continues to support/record more and more data.

This design session is to discuss how Ceilometer scales to handle increasing amount of data captured by increasing amount of items it meters/monitors/alarms. How do we design/implement Ceilometer to handle various stress levels on both the collector and backend (and what are the limits Ceilometer is expected to handle).

Ceilometer has the ability to deploy multiple collectors horizontally... is that enough and is there a better way? Also, what are the limits to what Ceilometer should collect (ie. collecting logging information will increase data load dramatically).

(Session proposed by gordon chung)


Wednesday November 6, 2013 11:15am - 11:55am
AWE Level 2, Room 203

11:15am

Scaling Horizon
Components in Horizon, e.g., Admin dashboard, do not scale to be useful in large scale deployments. Let's discuss work required to allow for a scalable user interface that works for administrators.

This topic ties in nicely with pagination, but also involves richer searching and filtering based on context.

(Session proposed by David Lyle)


Wednesday November 6, 2013 11:15am - 11:55am
AWE Level 2, Room 201A

11:15am

Neutron QA and Testing
During Havana we made some substantial progress with Neutron in the gate, however it's still not quite at the same level in the gate as other projects. This session will be a joint QA/Neutron session (held in the Neutron track) to address some of these issues. These include:

Full tempest gating - what stands between us and being able to remove the limitation that neutron can only run the smoke jobs.

Parallel testing support - what stands between us and being able to run tests parallel against neutron environments.

Upgrade testing - what are the plans for getting neutron into grenade's configuration and upgrade testing.

(Session proposed by Sean Dague)


Wednesday November 6, 2013 11:15am - 11:55am
AWE Level 2, Room 201C

11:15am

Nova Project Structure and Process
The Nova project has been growing rapidly. With this growth comes some growing pains. Let's discuss the project's leadership structure and the processes used to manage our work. In particular, we'll discuss some areas where we need people to step up and lead, as well as some changes to blueprint review and prioritization for Icehouse.

It is particularly important for those involved with leading sub-teams to come to this session, so that we have a clear understanding of how the process will work this cycle.

(Session proposed by Russell Bryant)


Wednesday November 6, 2013 11:15am - 11:55am
AWE Level 2, Room 204-205

11:15am

I18n policies of messages
There are several kinds of messages in OpenStack, all in same domain, for example, log messages, API response messages, command line response messages, and so on.

This session will discuss the I18n policies to these messages. Following questions will be addressed in this session:

1. What kinds of messages are user facing messages? What messages are not user facing messages? What kinds of messages should be translated?
2. Does it need to separate messages into different domains? How to separate them into different domains?


(Session proposed by Ying Chun Guo)


Wednesday November 6, 2013 11:15am - 11:55am
AWE Level 2, Room 201B

11:15am

Neutron QA and Testing
During Havana we made some substantial progress with Neutron in the gate, however it's still not quite at the same level in the gate as other projects. This session will be a joint QA/Neutron session (held in the Neutron track) to address some of these issues. These include:

Full tempest gating - what stands between us and being able to remove the limitation that neutron can only run the smoke jobs.

Parallel testing support - what stands between us and being able to run tests parallel against neutron environments.

Upgrade testing - what are the plans for getting neutron into grenade's configuration and upgrade testing.

(Session proposed by Matthew Treinish)


Wednesday November 6, 2013 11:15am - 11:55am
AWE Level 2, Room 202

12:05pm

PaaS Event Usage Collection
This session will include the following subject(s):

PaaS Event Usage Collection:

Ceilometer must be able to efficiently extract and process usage information from services in order to properly generate bills. In order to be able to efficiently process usage data, ceilometer requires services to implement a consistent interface. This document describes the metering requirements, use cases and provides a architecture for collection of usage information from Platform as a Service (PaaS) offerings.

(Session proposed by Phil Neal)

PaaS Event Format for Ceilometer Collection :

Up until recently the focus of OpenStack has been on infrastructure level services (compute, storage, networking), but there are a large number of PaaS services that are currently in development and also a growing number of applications running on OpenStack systems. Many of these new applications will need to be metered for a variety of reasons: internal systems management, license management, end customer billing. Ceilometer currently supports collection of metering information for infrastructure level services. The general mechanism has been to either create a targeted agent or use the existing service APIs to meter these systems. While this approach has worked for the existing set of services, it will run into a several problems as the number of PaaS and SaaS services that need to be metered expand. The main issue is that it will not be viable to do custom integrations for the potentially hundreds (and eventually thousands) of services that may be hosted in OpenStack. This blueprint provides a proposal for standardizing the format of integrations so that Ceilometer can consume metering data from any conforming application without doing any custom integration or even a code change.

(Session proposed by Phil Neal)


Wednesday November 6, 2013 12:05pm - 12:45pm
AWE Level 2, Room 203

12:05pm

Automated Dashboard Generation
Horizon cannot hope to keep up with the number of new services provided by the continually growing set of projects. Other dashboards (such as the AWS console) use dependency injection and code generation from schemas to allow the burden to be largely automated. Let's discuss how this might work in Horizon and how we can move more of that workload onto the projects creating these features.

A couple of suggested approaches:

* An approach that combines Progressive Enhancement with the automated consumption of simplistic HTML generated by the remote projects would allow the Horizon team to focus on enhancing the user experience.

* The Django admin builds complete admin interfaces based on Django's "Model" classes. If we could consume a specification from each service for their "models" we could do some introspection and code generation and end up with something very powerful and flexible.

NOTE: This session was originally proposed for Keystone, but it really belongs under Horizon. Horizon is going to need to set the standards for the other projects in order to continue to have a workable growing UI.

NOTE 2: This session proposal has been edited by Gabriel Hurley to merge two related topics into one.

(Session proposed by Adam Young)


Wednesday November 6, 2013 12:05pm - 12:45pm
AWE Level 2, Room 201A

12:05pm

Neutron Loadbalancing service (LBaaS)
This session will include the following subject(s):

Icehouse – topics for LBaaS:

a summary of all relevant discussions around LBaaS at: http://goo.gl/QvINBh

In addition to the proposals the following should be addressed on the "generic" API level:

L7 rules - https://blueprints.launchpad.net/neutron/+spec/lbaas-l7-rules

Also, using the extension proposal by Eugene, we would like to implement "template" based declarative mechanism - https://blueprints.launchpad.net/neutron/+spec/lbaas-template-engine

(Session proposed by Samuel Bercovici)

Neutron Loadbalancing service (LBaaS):

We will discuss feature roadmap for Icehouse.
Key points:
- object model change (vip and pool relationship), loadbalancer instance.
- extensible API/capabilities/vendor plugin drivers
- the concept of noop-driver/"backendless" configuration


Also we will cover vendor driver contribution.
Corresponding etherpad link: https://etherpad.openstack.org/icehouse-neutron-lbaas

(Session proposed by Eugene Nikanorov)


Wednesday November 6, 2013 12:05pm - 12:45pm
AWE Level 2, Room 201C

12:05pm

Rethinking scheduler design
Currently the scheduler exhaustively searches for an optimal solution to requirements given in a provisioning request. I would like to explore breaking down the scheduler problem in to less-than-optimal, but "good enough" answers being given. I believe this approach could deal with a couple of current problems that I see with the scheduler and also move us towards a generic scheduler framework that all of OpenStack can take advantage of:

-Scheduling requests for a deployment with hundreds of nodes take seconds to fulfill. For deployments with thousands of nodes this can be minutes.

-The global nature of the current method does not lend itself to scale and parallelism.

-There are still features that we need in the scheduler such as affinity that are difficult to express and add more complexity to the problem.

Etherpad: https://etherpad.openstack.org/p/RethinkingSchedulerDesign

IRC discussion: #openstack-scheduling on freenode


(Session proposed by Michael H Wilson)


Wednesday November 6, 2013 12:05pm - 12:45pm
AWE Level 2, Room 204-205

12:05pm

oslo.messaging - API design, plans for Icehouse
The oslo.messaging API was designed and developed during the Havana cycle. The plan is to adopt it early in the Icehouse cycle.

This session will first review some of the key API design decisions to make sure we have a consensus on the design: http://docs.openstack.org/developer/oslo.messaging/

Then we will discuss our plans for Icehouse - adoption by all projects, removal of rpc from oslo-incubator, driver refactoring, completing the message security, a notifications client, a qpid/proton client, python3 support, etc.

(Some of the above may warrant a separate session if anyone cares to propose them)

See also: https://etherpad.openstack.org/HavanaOsloMessaging

(Session proposed by Mark McLoughlin)


Wednesday November 6, 2013 12:05pm - 12:45pm
AWE Level 2, Room 201B

12:05pm

Tempest Policy in Icehouse
Over time we've created a lot culture around the right and wrong ways to get code into tempest, where things are appropriate, the process by which we allow skips. We should set aside a session to capture all the lore we all agree on into an etherpad so that it can get turned into official documentation for the project.

We should also take a look forward at some of the questions and challenges that core team members are having with reviews. This includes how to address some of the new projects coming in, and what should be required of an integrated project.

(Session proposed by Sean Dague)


Wednesday November 6, 2013 12:05pm - 12:45pm
AWE Level 2, Room 202

12:45pm

Lunch
Wednesday November 6, 2013 12:45pm - 2:00pm
OpenStack Quad

1:20pm

Lightning talks
A Lightning Talk is a short presentation, no longer than 5 minutes. Unlike other presentations at the OpenStack Summit. the lightning talks are unstructured and can be about anything: from code, to running, to any hobby you may have. You can use slides but the 5 minutes need to take into account setting up of your equipment.
You sign up for giving the talk the same day you'll want to deliver it. Participate to the opening sessions every day for more details.
Be creative and have fun.

Wednesday November 6, 2013 1:20pm - 1:50pm
Expo breakout room 1 & 2

2:00pm

Extended stats filtering
This session will include the following subject(s):

Extended stats filtering:

Nowadays user can get 4 statistics for a given metric: max, min, avg and sum. Generally speaking, there are a lot more of potentially interesting aggregates to be calculated for the given metrics. As the first step I would like to propose to add filtering capabilities for existing statistics. This feature would provide user with ability to provide criteria to select the events that would influence counters. Here are few examples of the use cases:
1. Ceilometer may provide statistics about instances booted from the concrete image
2. Statistics for instances colocated in subnet

Also It would be good if user will be able to dynamically create such filters and combine several metrics together.

(Session proposed by Nadya Privalova)

Improving Ceilometer API query filtering:

The current version of Ceilometer API supports a simple query filtering option with a logical AND relation between the fields. This solution results in multiple calls towards the API, when there is a list of requested elements (samples or statistics). The API can be improved to support lists in the fields of a query filter.

This improvement makes it possible to retrieve the samples of one or more meters for one or more resources in one API call and also supports to get the statistics of multiple resources with a single API request.

(Session proposed by Ildiko Vancsa)


Wednesday November 6, 2013 2:00pm - 2:40pm
AWE Level 2, Room 203

2:00pm

Mini-Sessions: Gateway Port Forwarding and Switch Port Ext
This session will include the following subject(s):

Neutron Switch Port Extension:

For services hosted in virtual machines or in namespaces, their interface plugs into a Neutron port which at most times maps to a virtual switch port (such as OVS port). Neutron is aware of this port and as such can establish the required network connectivity for that interface and service. However, when a service that is realized on a physical appliance is connected to a physical switch's port, it is often not possible to discover the location of this service to be able to provide the required network connectivity. We will discuss an extension to the port resource which can help solve this issue.

(Session proposed by Sumit Naiksatam)

Add port forwarding from gateway to internal hosts:

This BP virtually intends to implement a DNAT on routers. It enables outside to access internal hosts via different port on gateway IP.

This feature is important for running openstack as IaaS. It is important for a public cloud user to create a router and apply port forwarding and firewall rules to his/her internal network.

(Session proposed by Jianing YANG)


Wednesday November 6, 2013 2:00pm - 2:40pm
AWE Level 2, Room 201C

2:00pm

Nova Un-conference (Wednesday)
This session will give an opportunity to cover a variety of topics for 10 minutes each. If you would like to participate, please sign up for a slot on the following etherpad.

https://etherpad.openstack.org/p/NovaIcehouseSummitUnconference

(Session proposed by Russell Bryant)


Wednesday November 6, 2013 2:00pm - 2:40pm
AWE Level 2, Room 204-205

2:00pm

oslo.config enhancements
This session will include the following subject(s):

Local conf objects and sample conf file generation:

As more projects started to interoperate in OpenStack, services are refraining use of global configuration objects and switching to local objects.

However this has an impact on generating sample config files, since the generator script relies on the global object. We have consensus that sample config files are needed but the overall coverage is regressing as more config objects are going local.

http://lists.openstack.org/pipermail/openstack-dev/2013-June/010315.html

Let discuss how we can manage to use local config objects and still identify all options.

(Session proposed by Zhongyue Luo)

Removing import-time side-effects from oslo.config:

Most apps use oslo.config by relying on options to be registered as code is loaded. Many modules throughout the OpenStack code base have blocks that import the global config object from oslo.config and then register options on the object. This means importing a module changes global state shared by the application, in a way that cannot be undone or reproduced by unit tests. This proposal describes a way to avoid having import-time side-effects while maintaining our current level of discoverability.

(Session proposed by Doug Hellmann)


Wednesday November 6, 2013 2:00pm - 2:40pm
AWE Level 2, Room 201B

2:00pm

Who watches the watchers - aka Tempest Unit Tests
During H3 I added some unit tests for tempest. The only tests there right now are very basic and just verify that the wrapper scripts that are used in tox return the correct exit code on success or failure (which was prompted by a bug in one script that super-fixed the gate for a few hours, ie every test always passed)

In the icehouse cycle it would good to start seeing unit tests being added for tempest so that we can verify that tempest works correctly. So, I think it'll be good to have a discussion on which parts of tempest require unit testing and how we should go about implementing them. In addition to anything else related to verifying that tempest itself works as expected and that we don't introduce any regressions through changes to the tempest code.

aka Quis custodiet ipsos custodes

(Session proposed by Matthew Treinish)


Wednesday November 6, 2013 2:00pm - 2:40pm
AWE Level 2, Room 202

2:00pm

Moving Trove integration tests to Tempest
Right now we use redstack (trove-integration) for all our integration testing needs. How do we move to Tempest so that our tests can be used to gate check-ins. Let's discuss what needs to happen, and how we can go about getting it done.

https://etherpad.openstack.org/p/TroveTempestTesting

(Session proposed by Nikhil)


Wednesday November 6, 2013 2:00pm - 2:40pm
AWE Level 2, Room 201A

2:50pm

A fully-realized query API
This session will include the following subject(s):

A fully-realized query API:

Ceilometer currently supports a limited amount of functionality when querying via the API. We can filter timestamps based on a range and we can search other attributes based on equivalence. This will not be sufficient as the metadata contains more and more valuable information. Also, with the addition of Events, we will need to expand the API support to enable filtering there as well.

how do we create an interface that allows unrestricted filtering of data and can it be backend-agnostic.

(Session proposed by gordon chung)

API improvements:

A grab of topics related to potential improvements in the API:

* support a wider range of statistical aggregates (e.g. standard deviation, rate of change, moving window averages)

* selectable aggregation functions on statistics query

* complete pagination support started in Havana

* can we continue to evolve the v2 API, or do we need to start considering rev'ing it again to v3?

This session is intended as a placeholder for all API-related discussion, so please feel free to add further ideas.

(Session proposed by Eoghan Glynn)


Wednesday November 6, 2013 2:50pm - 3:30pm
AWE Level 2, Room 203

2:50pm

Neutron Pain Points
A survey of some of the usability and development challenges faced by Neutron to encourage consensus on how such issues might be best addressed.

Shortlist of suggested issues to discuss:

Usability

Application developers whose primary concern is logical connectivity may complain that the current set of Neutron primitives (Network, Subnet, Port) are confusing. Network engineers may complain that Neutron does an insufficient job of exposing networking primitives. How can Neutron provide better usability for these types of users?


Reliability

Neutron is becoming more feature-full with each release but quality is suffering. What strategies can we employ to reverse this trend?


Complexity

The complexity of Neutron has been increasing as more and more control-plane functionality is included. Should this trend be allowed to continue, or should the role of Neutron be reduced to providing glue between OpenStack and 3rd party networking options?

(Session proposed by Maru Newby)


Wednesday November 6, 2013 2:50pm - 3:30pm
AWE Level 2, Room 201C

2:50pm

Smarter resource placement for intense workloads
Intense workloads on Openstack are here to stay. This require us to place aggregate/group workloads (in terms of compute, storage, network) in an optimal fashion to effectively utilize available resources. Over the last few months, the scheduler subgroup has made good progress in defining new directions for the scheduler. In this session, in addition, we discuss placement algorithms and constraints that are aligned with the subgroup activities.

https://docs.google.com/document/d/1cR3Fw9QPDVnqp4pMSusMwqNuB_6t-t_neFqgXA98-Ls/edit#heading=h.sxmednu8fdh5

Collaborators:
* Gary Kotton
* Yathi Udipi

(Session proposed by Debo~ Dutta)


Wednesday November 6, 2013 2:50pm - 3:30pm
AWE Level 2, Room 204-205

2:50pm

Rootwrap: Icehouse plans
During the Havana cycle we focused on getting all consuming projects (Nova, Cinder, Neutron) to use the oslo-incubator version of rootwrap.

The next step now is to look into how those projects actually use rootwrap, and make improvements to that (on both sides). The current state is a bit sad with old configuration options still being used (I'm looking at you, Neutron and processutils), unrestrictive filters (the basic "CommandFilter" is used way too often), missing granularity (all volume drivers in Cinder share the same filter file) and commands being allowed as root while not strictly necessary (can achieve the same results without running as root so much). We'll discuss where to focus our efforts (nodes that could actually avoid all escalation mechanisms) and identify who would be interested to handle which area.

We'll also use this session to discuss potential replacements to rootwrap, or how we could solve the performance bottlenecks due to executing a new python process for each command being shelled out as root.

Finally, we'll discuss how far we are from making rootwrap a standalone library, and if that's a good idea to begin with.

(Session proposed by Thierry Carrez)


Wednesday November 6, 2013 2:50pm - 3:30pm
AWE Level 2, Room 201B

2:50pm

Tempest Stress Test - Overview and Outlook
With bp stress-tests a new way of stress testing was introduced. This session will shortly show what is the current state of the implementation and we can discuss about the future steps.

(Session proposed by Marc Koderer)


Wednesday November 6, 2013 2:50pm - 3:30pm
AWE Level 2, Room 202

2:50pm

Trove Current Heat Integration
the Trove heat codepath is currently lacking. It needs to be built out, and support multiple templates and things like cloud init. We need to define a list of criteria we want to support and how we would like to support them.

https://etherpad.openstack.org/p/TroveHeatSupport

(Session proposed by Michael Basnight)


Wednesday November 6, 2013 2:50pm - 3:30pm
AWE Level 2, Room 201A

3:40pm

Roll-up of sample data
Currently ceilometer supports only the two extremes of data retention:

* keep everything for always (the default behavior)
* discard data older than a configured age (via the database.time_to_live option)

However there are many usecases where while fine-grained data doesn't need to persist forever, we also don't want older data to suddenly fall off a cliff when it gets to a certain age.

In these cases, a roll-up scheme would be more convenient, such these data as they age are distilled into progressively coarser grained aggregates before being eventually completely expired. As such these data would become gradually more condensed without losing all of their value for trend analysis, before finally being aged out altogether.

This feature would be driven by configured policies, so that for example certain meters are retained forever, whereas others are aggressively rolled up with data older than say one week being aggregated hourly, data older than month being aggregated daily, and so on.

This session will explore the feasibility of implementing such a scheme across the various storage drivers.

(Session proposed by Eoghan Glynn)


Wednesday November 6, 2013 3:40pm - 4:20pm
AWE Level 2, Room 203

3:40pm

L3 advanced features
The aim of this session is to discuss the following topics related to L3 features supported by Neutron plugins.

1) Dynamic Routing
2) Support for multiple external gateways

Dynamic Routing
------------------
In a nutshell: so far Neutron L3 implementations only leverage static routes; dynamic routing should be a potentially desirable new feature.

Scenarios:
A) dynamic routing between Neutron routers
B) dynamic routing between Neutron routers and external systems

The goals of the session would be:
1) Reach a consensus over whether this something that should be targeted to Icehouse release, and which scenarios should be supported
2) Decide which routing protocols should be supported and in which scenarios (e.g. OSPF and RIPv2 for internal routing, BGP for external routing)
3) Identify the APIs Neutron should expose for configuring external routing
4) Provide a high level roadmap for support in the l3 agent and identify potential bottlenecks


Multiple External Gateways
--------------------------
In a nutshell: Extend the L3 API to allow for setting multiple gateways on a Neutron router

Typical scenario: http://en.wikipedia.org/wiki/Equal-cost_multi-path_routing

During the session the community should agree on whether this is something which make sense for Neutron routers, and if positive, discuss a roadmap for API changes and support in the l3 agent.

***********************************
- Blueprint links TBA

(Session proposed by Salvatore Orlando)


Wednesday November 6, 2013 3:40pm - 4:20pm
AWE Level 2, Room 201C

3:40pm

Extensible Scheduler Metrics
Session Lead(s): Paul Murray (HP)

Context is how to create a mechanism that allows new resource metrics to be added to the scheduler
in a flexible way.

User Stories:
- I want to be able to define a new filter that tracks network badwidth entitlement
- I want to be able to define a new filter that tracks cpu entitilement
- I want to be able to schedule based on utilization.
- I want to be able to schedule based on power consumption.
.... PCI-style metrics in scheduling ('I have a limited number of X per host' versus continuous (CPU) or nearly so (memory) metrics)

References:
https://blueprints.launchpad.net/nova/+spec/network-bandwidth-entitlement
https://blueprints.launchpad.net/nova/+spec/cpu-entitlement
https://blueprints.launchpad.net/nova/+spec/utilization-aware-scheduling


Topics for discussion:

* What should the Nova scheduler's relationship be with Celiometer ? Possible answers are:
- Provide metrics to Ceilometer (or, at least, offer the same sources to Ceilometer)
- Optionally Consume additional metircs from Ceilometer for advanced scheduling
- Depend on Ceilometer for metrics
- An extensible plugin framework on nova compute node to collect various metrics data to be used by nova schedulers, that kind of data could also be sent to ceilometers for other advanced usages like alarming.

* What needs to be changed in the current Nova data model (flavours / compute_nodes)
- See https://docs.google.com/document/d/1m7Uda4lgNOyAUnlJuHi2m1nqjp1Gi4T13RBUNBgDhNM

(Session proposed by Lianhao Lu)


Wednesday November 6, 2013 3:40pm - 4:20pm
AWE Level 2, Room 204-205

3:40pm

State of affairs in DB schema migrations
Topics to discuss:

1. sqlalchemy-migrate needs a new stable release

Distros use the patched versions of sqlalchemy-migrate to make it compatible with SQLAlchemy 0.8.x releases. The fix is really simple and is already merged to master branch of sqlalchemy-migrate repo on stackforge. We should make a new stable release of sqlalchemy-migrate as a first step to having SQLAlchemy>=0.8.1 in global requirements list.

2. sqlalchemy-migrate is rather old and we'd better switch to alembic as soon as possible (new features, bug fixes, compatibility with new SQLAlchemy versions/etc)

sqlalchemy-migrate had not been maintained for some time, so we start to catch more and more bugs in its compatibility with newer versions of SQLAlchemy (e. g. https://bugs.launchpad.net/nova/+bug/1241038). We could continue to fix it ourselves, but a simpler (and, I believe, the right one) approach would be to switch to Alembic.

3. Problems with switching to Alembic

1) our tests are run on SQLite in-memory DB and we use migrations to obtain the initial DB schema, but Alembic doesn't support ALTER in SQLite on purpose (sqlalchemy-migrate implements it by using a couple of hacks)

so we should use models definitions to generate the initial DB schema for running tests, but

2) we can't use models definitions to generate the initial DB schema right now, because models are out of sync with migrations (so the schema obtained by applying of migration scripts and the one generated from models definitions MAY be different, please see the blueprint below for more information)

and

3) switch to Alembic would mean dropping migrations support on SQLite (and Debian/Ubuntu OpenStack packages maintainers) would not be glad

Blueprints below provide more information on how sqlalchemy-migrate and alembic can live together in Ceilometer + explain out-of-sync problem in details.

(Session proposed by Roman Podolyaka)


Wednesday November 6, 2013 3:40pm - 4:20pm
AWE Level 2, Room 201B

3:40pm

Parallel tempest moving forward
The week before feature freeze in havanna we switched tempest over from running tests serially to run all of its tests in parallel using testr. This greatly improved runtime and made tempest finish executing in about the same amount of time as the py26 unit tests for some of the other projects(20-30mins). Additionally, this helps shake loose more bugs in the projects by making multiple requests at once which more closely simulates an actual workload. However, moving to parallel execution came at the cost of changing how tests interact with each other and an increased risk of nondeterministic failures in the gate.

So moving into icehouse I think it's important that we discuss what additional changes need to be made to further improve parallel stability and if there are any other optimizations that we can make to improve tempest performance. Also, it will be a good forum to discuss things to watch out for when adding tests to tempest and possibly adding automated checks to catch common parallel execution issues before we merge them.

(Session proposed by Matthew Treinish)


Wednesday November 6, 2013 3:40pm - 4:20pm
AWE Level 2, Room 202

3:40pm

Trove Datastore Clustering
We have defined what we think is a good shot at the clustering api. Lets, as a group, review it and toss out our ideas, and try to blow holes in it.

We also need to gather high level requirements, such as rack awareness, that a Clustering system needs to define.

https://etherpad.openstack.org/p/TroveReplicationClustering

(Session proposed by Michael Basnight)


Wednesday November 6, 2013 3:40pm - 4:20pm
AWE Level 2, Room 201A

4:20pm

Break
Wednesday November 6, 2013 4:20pm - 4:40pm
OpenStack Quad

4:40pm

Future of alarming
For Havana, alarm evaluation is based on a service at arms-length from the metering pipeline, which retrospectively polls the statistics API over the configured evaluation window with the query constraints for each alarm rule.

There has been some discussion about moving the alarm evaluation logic into the sample/event ingestion pipeline.

The purpose of this session is to gather together the stake-holders in the alarming feature and trash through the potential benefits and pit-falls of such an approach.

(Session proposed by Eoghan Glynn)


Wednesday November 6, 2013 4:40pm - 5:20pm
AWE Level 2, Room 203

4:40pm

Zuul job runners and log management
This session will include the following subject(s):

Log management:

We should decide on a plan for how to deal with log storage, processing, serving, etc for all the logs that are produced from our test runs.

See this mailing list thread on the subject:

http://lists.openstack.org/pipermail/openstack-infra/2013-October/000327.html

(Session proposed by James E. Blair)

Job runners for Zuul:

Let's design a non-Jenkins job runner for Zuul. Rough starting requirements:

* Distributed (no centralized 'master' architecture)
* Secure (should be able to run untrusted jobs)
* Should be able to publish artifacts appropriate to a job's security context
* Lightweight (should do one job and simply)


(Session proposed by James E. Blair)


Wednesday November 6, 2013 4:40pm - 5:20pm
AWE Level 2, Room 202

4:40pm

python-keystoneclient: APIClient & auth_plugins
https://etherpad.openstack.org/p/icehouse-python-keystoneclient

python-keystoneclient has been holding off taking nova's auth_plugin mechanism for a while now and it's not because we believe it to be a bad idea. Instead we want to go further.

The concept has been discussed under the term APIClient but involve separating the communication, authentication and API call areas of concern and having common communication mechanisms amongst all the OpenStack clients.

The communication object should be responsible for:
- CA and User x509 Certificates
- Kerberos
- User Agents and common headers

Authentication objects (pluggable) should utilise and be attached to the communication object and provide abstraction for:
- Username and Password authentication
- Token endpoint auth
- All the new mechanisms that are upcoming and/or third party.
In this way requests made via the communication object (whether they come from a client or not) are authenticated and secure.

The Client object then is left to manage the API calls to it's own services.
- Users, projects, domains etc

Once we have this reusable communication object this is something that can/should be reused by all the different clients, however it needs to originate from keystoneclient as the authentication hub.

See this blog post for more: http://www.jamielennox.net/blog/2013/09/27/apiclient-communications/

(Session proposed by Jamie Lennox)


Wednesday November 6, 2013 4:40pm - 5:20pm
AWE Level 2, Room 201B

4:40pm

Extensibility of Modular Layer 2
This session will include the following subject(s):

ML2: More extensible TypeDrivers:

The current ML2 TypeDrivers assume that ML2 is managing segmentation types via the TypeDrivers. What we've noticed while developing MechanismDrivers for an array of SDN Controllers is the fact they want to control the segmentation type and perhaps even the segmentation ID. The current ML2 TypeManager assumes an integer for a segmentation ID, but a controller MechanismDriver may want to allocate something other than an integer. Additionally, controller-based TypeDrivers may require interactions with the controller for allocating and de-allocating segmentation IDs. A good discussion around this use case for ML2 would be great to have.

(Session proposed by Kyle Mestery)

ML2: RPC handling in ML2:

Currently, RPC handling is done at a higher layer in the ML2 plugin. This works great for the existing RPC calls supplied and consumed by the OVS, LB, and Hyper-V agents. But we've hit some problems when additional RPC calls are needed by a specific MechanismDriver. There is no clean way to do this currently. Additionally, it's conceivable a controller-based SDN MechanismDriver may want to listen for RPC calls. The current infrastructure doesn't allow this.

(Session proposed by Kyle Mestery)


Wednesday November 6, 2013 4:40pm - 5:20pm
AWE Level 2, Room 201C

4:40pm

Instance Group Model and API Extension
An instance group provides a mechanism to describe a topology of instances and the relationships between them, including the policies that apply to them. This is useful to create/schedule a group of instances, where we would like to apply certain policies like “anti-affinity”, “network-proximity”, “group-affinity”, etc., to a specific set of groups, and create them as a whole.

This is highly applicable for the Smart Resource Placement effort, and the APIs are the starting point for making combined smart decisions for scheduling the entire topology.

Scheduler meeting minutes on the API discussion:
http://eavesdrop.openstack.org/meetings/scheduler/2013/scheduler.2013-10-08-15.04.html

https://docs.google.com/document/d/17OIiBoIavih-1y4zzK0oXyI66529f-7JTCVj-BcXURA/edit?usp=sharing

Collaborators: Yathi Udupi, Debo Dutta, Mike Spreitzer, Gary Kotton

(Session proposed by Yathiraj Udupi)


Wednesday November 6, 2013 4:40pm - 5:20pm
AWE Level 2, Room 204-205

4:40pm

Zero Downtime Trove Upgrades
Go over strategy to upgrade GuestAgent, TaskManager, and API without incurring downtime. Also touch on ensuring version compatibility with RPC versioning.

https://etherpad.openstack.org/p/TroveUpgradesNoDowntime

(Session proposed by Vipul Sabhaya)


Wednesday November 6, 2013 4:40pm - 5:20pm
AWE Level 2, Room 201A

5:30pm

Tighten model
Ceilometer does not enforce any kind of relationship on the model it provides in the database drivers.
But it does so in the API for example.

Let's clean that

(Session proposed by Julien Danjou)


Wednesday November 6, 2013 5:30pm - 6:10pm
AWE Level 2, Room 203

5:30pm

More Salt in Infra
Taking a look at what bits and pieces of Infra could work well with Salt.

(Session proposed by Anita Kuno)


Wednesday November 6, 2013 5:30pm - 6:10pm
AWE Level 2, Room 202

5:30pm

python-keystoneclient: middleware & caching
https://etherpad.openstack.org/p/icehouse-python-keystoneclient

A more generalized how to fix keystoneclient and what needs to be done.

Possible topics:
- Version and Extension discovery - what are the performance implications of this? How does client deal with optional server components? Given the v2 and v3 client interfaces are completely different how would this be realistically used?
- auth_token middleware uses httplib directly rather than consuming the rest of keystoneclient
- Caching - what makes sense and how do we do it in a client lib?

However i'm willing to turn this into a discussion of whatever gets people more interested in the client.

(Session proposed by Jamie Lennox)


Wednesday November 6, 2013 5:30pm - 6:10pm
AWE Level 2, Room 201B

5:30pm

Modular Layer 2 QoS and Deprecated Plugin Migration
This session will include the following subject(s):

Quality of Service API extension:

Updates on the current status of a vendor-neutral Quality of Service API extension in Neutron.

(Session proposed by Sean M. Collins)

ML2: Migration from deprecated plugins:

The Open vSwitch and LinuxBridge plugins are planned for deprecation in the Icehouse timeframe. This session will discuss what we as a team would like to do with regards to migrating people from these plugins into the ML2 plugin. Perhaps we want to automate this as much as possible.


(Session proposed by Kyle Mestery)


Wednesday November 6, 2013 5:30pm - 6:10pm
AWE Level 2, Room 201C

5:30pm

Adding plugability at the API layer
This idea started a while back while working with Cinder and Lunr. When you already have a system that provides all of the provisioning and coordination, it seems like a bit of overkill to have all of overhead of the rest of the infrastructure to just pass through api calls.

I would like to propose and discuss the idea of having a plugin capability at the api layer of nova and other nova like services.

1. This would provide a clean abstraction for back ends that are trying to integrate with nova that already provide the infrastructure for provisioning resources.

2. This would enable more opportunities to innovate and experiment within a project without causing disruption to the current codebase.

3. This would provide a cleaner way to implement api compatability for openstack services.

I would like to engage in a discussion to see if there is interest in the larger community with pursuing further, as I think down the road this will provide a lot more flexibility.

(Session proposed by creiht)


Wednesday November 6, 2013 5:30pm - 6:10pm
AWE Level 2, Room 204-205

5:30pm

Guest Agents in Trove
The OpenStack ecosystem plays host to a number of guest agents, tiny programs which help manage services or other components on provisioned servers. Trove also makes use of an agent to provision and manage datastores.

There are currently two known agents used for Trove- the so called "reference agent" found in the Trove repository as well as Sneaky Pete which is currently used by Rackspace. Both suffer from architectual issues with how they communicate with Trove (some of which will hopefully be resolved by the work on Conductor).

Let's get together and discuss the way that Trove's relationship with agents as well as the agents themselves can be improved.

https://etherpad.openstack.org/p/TroveGuestAgents

(Session proposed by Michael Basnight)


Wednesday November 6, 2013 5:30pm - 6:10pm
AWE Level 2, Room 201A
 
Thursday, November 7
 

9:00am

Feature parity in storage drivers
Our storage drivers have drifted apart as new features have been added. We should settle on one preferred driver that will always be maintained as feature complete, and then allow other drivers to lag as needed based on implementation. We also need a good way to document exactly which features are and are not supported, from the perspective of an API user.

(Session proposed by Doug Hellmann)


Thursday November 7, 2013 9:00am - 9:40am
AWE Level 2, Room 203

9:00am

Read-only API role
Admin-only requirements in code and policy end up conflicting so that you can't have a pure read-only role that can list all volumes/snapshots/etc. This means that a logging / diagnositics / dashboard tool needs full admin creds, which are dangerous if leaked.

Can we fix this?

(Session proposed by Duncan Thomas)


Thursday November 7, 2013 9:00am - 9:40am
AWE Level 2, Room 201B

9:00am

Integration testing for Horizon
We mock a lot and end up relying heavily on manual testing to find out when one of the many APIs we depend on has changed in a backwards incompatible way, and other surprises. Horizon would greatly benefit from a wider set of integration tests that also exercises all of our interfaces to other projects.

Suggestions and issues to work through:

* How to write useful, durable tests that won't need to be modified all the time because e.g. a button's location has been adjusted?

* Implementation ideas:

* Separate, self-contained new tests?

* Part of the Django Selenium tests?

* A "mocking" switch that could turn mocking on or off: in e.g. a fully set up devstack environment, run the tests without mocking?

* Other ideas?

* Where should they live: in our tree to be easily modified alongside the main code, in Tempest, elsewhere?

* Tooling: Selenium, PhantomJS, CasperJS, Splinter, other...? Any previous experience to share?

(Session proposed by Julie Pichon)


Thursday November 7, 2013 9:00am - 9:40am
AWE Level 2, Room 201A

9:00am

PCI Passthrough : the next step
after base pci passthrough there is some requirement from pci passthrough customer, like:
https://bugs.launchpad.net/nova/+bug/1222990

here is the things to address:

1. PCI API: enable admin to get pci information from hypervisor, instance, show detail pci device info.
The initial code is at https://github.com/yjiang5/pci_api, what we needed is:
a) v2/V3 API support
b) test case
c) document


2. Enhance migration/attach/de-attach PCI devices, especially for
software-aware migration like bonding driver.

3. Enhance extra_info for PCI devices. Currently we have extra info in DB to contain PCI device information like network_id, switch_ip_address etc, but there is no method to configure it.

4.Enhance the PCI devices white list to support pci address level filter.

5. Add PCI test to openstack test framework

6. store stats in seperated table to avoid every minite update.

7.Change the PF_function to be 00:0000:00.0 format,to get a uniform fromat between diffrent component.


(Session proposed by Yongli He)


Thursday November 7, 2013 9:00am - 9:40am
AWE Level 2, Room 204-205

9:00am

Icehouse Vulnerability Management
The Vulnerability Management Team challenges for the Icehouse cycle:

- Clarify VMT scope, with projects being replaced by programs
- Evolution in the VMT processes
- Tooling/infrastructure needs
- Staffing up


(Session proposed by Thierry Carrez)


Thursday November 7, 2013 9:00am - 9:40am
AWE Level 2, Room 202

9:00am

Storage Policies (and other things)
The combination of the DiskFile and DBBroker refactorings and the erasure code work will allow Swift to support multiple storage policies in the same cluster. Regions, tiers, different encodings, and the combination of all of these are possible.

We'll discuss the current work being done on storage policies.

While I'll focus on the storage policy work, I also want to cover some of the topics discussed at the recent Swift hackathon such as cluster federation, discoverable features, and s-sync.

(Session proposed by John Dickinson)


Thursday November 7, 2013 9:00am - 9:40am
AWE Level 2, Room 201C

9:50am

Ceilometer integration testing
I'd like to propose the discussion about strategies of Ceilometer's integration testing.

Here is a short list of topics:
1. Tempest integration
2. Devstack + Ceilometer testing

We're working to define more detailed agenda, and appreciate any suggestions. I just wanted to remind PTL about this topic :)


(Session proposed by Nadya Privalova)


Thursday November 7, 2013 9:50am - 10:30am
AWE Level 2, Room 203

9:50am

Changing the wheels on a moving bus
Various people are deploying from trunk, and rolling upgrades are useful even if you only deploying stable releases.

The aim of this session is to collect data on what different people are doing, what the pain points are, what the policy on stability in trunk ought to be, and similar.

(Session proposed by Duncan Thomas)


Thursday November 7, 2013 9:50am - 10:30am
AWE Level 2, Room 201B

9:50am

Openstack dashboard to configure hardware
This will likely tie in to the session proposed by Jeremy about the future direction of Openstack Dashboard and UX, but would like to discuss the following -
1. Give a brief introduction to the new "Router" dashboard and demo how it is used. Find a better permanent solution for this dashboard?
2. What can be done to add new dashboards in future (UX perspective)?
3. Given that we now have a new "Router" dashboard, can we leverage that to add new panels for other hardware? Or will each hardware device require it's own dashboard?
4. Can multiple such dashboards/panels exist at the same time?
5. What can be done to make the operation of these dashboards dynamic - based on plugin detection, config setup?

(Session proposed by Abishek Subramanian)


Thursday November 7, 2013 9:50am - 10:30am
AWE Level 2, Room 201A

9:50am

The road to live upgrades
We have made progress over the last few releases towards supporting live rolling upgrades of Nova. Let's get together again to review the status of this effort and the items we would like to accomplish in Icehouse.

(Session proposed by Russell Bryant)


Thursday November 7, 2013 9:50am - 10:30am
AWE Level 2, Room 204-205

9:50am

Stable branch maintenance
In this session we'll review the current state of stable branch maintenance and review potential process evolution:

- fewer supported releases ?
- dependency capping ?
- need for point releases ?
- accepted patches ?
- relationship with security maintenance ?

Any downstream consumer interested in sharing the load of handling bugfix backport should join us to discuss the best way to solve this as a community.

(Session proposed by Thierry Carrez)


Thursday November 7, 2013 9:50am - 10:30am
AWE Level 2, Room 202

9:50am

Swift Profiling Middleware and Tools
Swift Performance tuning is a big topic. The current Swift profiling method monitor the cluster and provide system and process level statistics information which can tell how well the system is running. But it doesn't provide more details about code level information and explain why. This data is needed to enable understanding and improving the performance of the Swift core code. This proposal can give us deeper analysis into the code and tell what happened in the background and explain why. For example:
How often the function in specific module is called?
How long it take to execute these calls?
Where's the most time consumed?
Why does the response time of container PUT operation increase?
Where does the memory leaking happen? how much memory consumed by specific code snippet?

The middleware being discussed has been proposed at https://review.openstack.org/#/c/53270/

(Session proposed by Edward)


Thursday November 7, 2013 9:50am - 10:30am
AWE Level 2, Room 201C

10:30am

Break & Keysigning
NB: People interested in PGP keysigning will informally converge to the Developer Lounge during this break. Details at https://wiki.openstack.org/wiki/OpenPGP_Web_of_Trust/Icehouse_Summit

Thursday November 7, 2013 10:30am - 11:00am
AWE Level 2, Developer lounge

11:00am

Heat Software Orchestration
Heat is lacking in the terms of orchestration of software deployments between nodes/servers/instances. With the new HOT DSL we would like to talk about how to develop the HOT DSL language to support more advanced orchestration in a declarative fashion while minimizing complexity and keeping templates readable.

Related information:
https://wiki.openstack.org/wiki/Heat/Software-Configuration-Provider

(Session proposed by Thoms Spatzier)


Thursday November 7, 2013 11:00am - 11:40am
AWE Level 2, Room 203

11:00am

UX and Future Direction of OpenStack Dashboard
Horizon (OpenStack Dashboard) has a lot of potential for improvements from the look and feel of the UI. In this session I would like to open and discuss:
* How to approach UX related questions and include UX professionals into development processes
* Which parts of Horizon we can attack in the future
* Propose and discuss some ideas for improvements
* Open discussion

(Session proposed by Jaromir Coufal)


Thursday November 7, 2013 11:00am - 11:40am
AWE Level 2, Room 201A

11:00am

Translation tools and scripts
Transifex is used to manage the translations, which now changes to close its source code. This session will re-evalute the available translation tools and have a discussion whether to turn to other open source translation management tools.

This session will also go through the scripts related with translation, the additional requirements, and the improvement plans in Icehouse.

(Session proposed by Ying Chun Guo)


Thursday November 7, 2013 11:00am - 11:40am
AWE Level 2, Room 202

11:00am

Nova Objects update and plans forward
We need to talk about the current state of objects, as well as what else needs to be done (hint: plenty). We also need to discuss breaking out the common base into Oslo so that other projects can use them.

(Session proposed by Dan Smith)


Thursday November 7, 2013 11:00am - 11:40am
AWE Level 2, Room 204-205

11:00am

Towards more structured & qualified notifications
Notifications API in Oslo is currently very generic and doesn't many structuring fields on the payload sent.
That doesn't help engine that would like to store, index and analyzes the event notifications.

Adding more documented fields that should/mut be present in notifiations could help a lot in this regard.

(Session proposed by Julien Danjou)


Thursday November 7, 2013 11:00am - 11:40am
AWE Level 2, Room 201B

11:00am

Swift Drive Workloads and Kinetic Open Storage
Follow up to the "Swift swift-bench workload analysis" at the previous design summit.
- Further observations of drive workloads under swift-bench
- Changes to the drive interface: going from block storage to a key/value API
- Overview of the Kinetic device and library APIs
- Seagate's Kinetic prototype Swift cluster
- Observations of Kinetic drive workloads

(Session proposed by Tim Feldman)


Thursday November 7, 2013 11:00am - 11:40am
AWE Level 2, Room 201C

11:50am

Heat workflow: consider taskflow, Mistral or other
We need to consider whether Heat's current task scheduling should be replaced with taskflow or Mistral

This session will cover the following topics:
* A general overview of taskflow and Mistral
* An overview of the current state of Heat's scheduling/workflow implementation
* A discussion of how Heat could utilize taskflow or Mistral
* Identifying some specific development that can be achieved in the Icehouse timeframe

http://www.mirantis.com/blog/announcing-mistral-task-flow-as-a-service/
https://wiki.openstack.org/wiki/TaskFlow
https://wiki.openstack.org/wiki/Convection

(Session proposed by Joshua Harlow)


Thursday November 7, 2013 11:50am - 12:30pm
AWE Level 2, Room 203

11:50am

Plugin architecture for Horizon
Currently adding stuff to horizon requires to change settings.py. This is nearly impossible in a world of software packages. At least, when using RPM packages, it is absolutely unwanted, to change files at install time, depending if other packages are installed or not. When implemented, this feature would make the life of packagers easier.

The idea would be a directory to place python packages to be added dynamically to the dashboard.

I'd like to hear opinions, ideas, and discussions about managing dynamic plugins, dependencies, etc...
Having such a feature would allow others to have their customization separate from horizon, or to provide software vendors to ship functions on top of horizon.

(Session proposed by Matthias Runge)


Thursday November 7, 2013 11:50am - 12:30pm
AWE Level 2, Room 201A

11:50am

elastic-recheck
Late in the Havana cycle we introduced elastic-recheck which uses logstash to find known gate bugs when a test run fails. In the short time the bot has been running it has been incredibly useful. Both at identifying known repeating failures and finding new bugs.

Moving forward there are improvements and features we'd like to see added to the bot including but not limited to:
* zeromq triggering from logstash when a test's logs are ready
* a different method of storing/managing queries (lp, in a db, separate git repo, etc.)
* reworking the recheck status page with graphs from logstash and integrating elastic-recheck more closely with the page.

This session will be the place to describe what additional features we should be adding to elastic-recheck and how we can enable the tool to be even more useful and automate more of test failure analysis.

(Session proposed by Matthew Treinish)


Thursday November 7, 2013 11:50am - 12:30pm
AWE Level 2, Room 202

11:50am

Metadata Service Enhancements: Callbacks + Network
Callbacks:

Building on set-password, provide a generic mechanism to set (but not overwrite) server metadata, so we can have a way to communicate with in guest actions. The existing user quotas on metadata should still apply.

Example use case: set "boot_complted_seconds=20" when looking to profile your actual boot times


Networking Information:

Lets look at improving the networking info given in both config drive and the metadata service to instances.

This would turn into a neutron API proxy, but it seems messy to have two metadata service API endpoints for users of openstack, so maybe this is the best trade-off? We could look at moving it into neutron, with neutron just proxying the nova information, but that makes config drive much harder to implement.

Example use case: have first interface configure via DHCP, but have other interfaces on private networks, and static configured.


More discussion here:
https://etherpad.openstack.org/IcehouseNovaMetadataService

(Session proposed by John Garbutt)


Thursday November 7, 2013 11:50am - 12:30pm
AWE Level 2, Room 204-205

11:50am

Merge logging and notifications
The current usage of notification and events logging are totally dissociated. It seems that it would be a good goal to slowly merge the two API to only keep one.

For example, the logging system would log to either a file (like currently) or to a RPC notification based event.
In the end, the notification system as it is today could be deprecated in favor of the generic logging mechanism.

(Session proposed by Julien Danjou)


Thursday November 7, 2013 11:50am - 12:30pm
AWE Level 2, Room 201B

11:50am

Plugging in Backend Swift Services
With the DiskFile abstraction in place for Icehouse development it becomes much easier to create extensions for the Swift Object Server and service requests to alternative storage systems.

To continue and expand on this work I'd like to briefly share my experience building on DiskFile and an alternative object replicator implementation for Swift on ethernet connected key-value drives [1]. Specifically what I discovered about where other storage implementations do not have to overlap with the existing filesystem/rsync implementation.

I'd like to engage the Swift community and seek input on how we can further divide the Swift backend storage system orchestration from implementation and discover emergent generalizations [2] that may be applicable to abstractions in to the Swift consistency engine as a whole.

The goal of the session is set of blueprints that can be refined, accepted, and developed during the Icehouse cycle.

1. Before the session, the kinetic-swift development codebase (which you can run on the Seagate Kinetic-Preview Simulator), will be publicly available as a reference to this work.
2. I'd call out gholt's ssync (https://review.openstack.org/#/c/44115/) specifically as another alternative implementation for the replicators that should inform how we should think about plugging in to backend Swift processes.

(Session proposed by Clay Gerrard)


Thursday November 7, 2013 11:50am - 12:30pm
AWE Level 2, Room 201C

12:30pm

Lunch
Thursday November 7, 2013 12:30pm - 1:50pm
OpenStack Quad

12:50pm

OpenStack Elections Town Hall
Please come and join members of Board of Directors election committee at the Demo Theater in the Expo Hall.  Join the audience and learn a little about how the board is evaluating the process and looking for ways to improve our board elections.  Committee members will be taking the stage to discuss the challenges and hurdles that it takes to effect change.  So, grab some food and come have a seat and interact with members of the board.  Thank you. 

Thursday November 7, 2013 12:50pm - 1:40pm
AWE Expo Hall

1:10pm

Lightning talks
A Lightning Talk is a short presentation, no longer than 5 minutes. Unlike other presentations at the OpenStack Summit. the lightning talks are unstructured and can be about anything: from code, to running, to any hobby you may have. You can use slides but the 5 minutes need to take into account setting up of your equipment.
You sign up for giving the talk the same day you'll want to deliver it. Participate to the opening sessions every day for more details.
Be creative and have fun.

Thursday November 7, 2013 1:10pm - 1:40pm
Expo breakout room 1 & 2

1:50pm

incremental backup API
currently, cinder backup API only support full volume backup, not support incremental volume backup.

When system running all the time, customer need to take snapshots for their volumes, it's better to backups incremental data changed between previous snapshot and current volume, than to backup the whole volume every time.
So, it's useful to support incremental volume backup to swift. when customer restor volume from snapshot, he can choose which incremental data and base volume image to use to restor that volume.

(Session proposed by David Wang)


Thursday November 7, 2013 1:50pm - 2:30pm
AWE Level 2, Room 201B

1:50pm

Autoscaling Design
We should confirm the design for Autoscale to be implemented in the Icehouse timeframe.

See also https://wiki.openstack.org/wiki/Heat/AutoScaling for the design proposal (which is linked to the blueprint).

(Session proposed by Christopher Armstrong)


Thursday November 7, 2013 1:50pm - 2:30pm
AWE Level 2, Room 203

1:50pm

Hardware management ramdisk
Ironic has, broadly speaking, two means to manage hardware:
* by booting a ramdisk with specialized functionality and performing actions locally
* over the network via OOB management tools

The REST and RPC APIs should expose a unified means to manage hardware, regardless of which driver is used, or whether that driver affects the nodes via the OOB mgmt interface or via local operations in a custom ramdisk.

We will discuss the API changes needed to expose various hardware management operations and the creation of a reference implementation, relying on a bootable ramdisk, for them.

* How do we expose these functions through the REST API?
* Who are the consumers of these functions? Cloud admins? Nova? Heat?
* Do we need an agent in the ramdisk with its own API?
* Do we need distinct ramdisks for different operations (eg, update-firmware, build-raid, erase-disks, etc)?
* How do we get logs back from the ramdisk, and how do we report errors back to the user?







This session will include the following subject(s):

Data protection for bare metal nodes:

The problem
------------------
There are several cases when private data might be accessible by third party users:
- A new user of a node provisions it with a smaller partition size than the previous one so some data might still remain on the volume.
- Previous user exceeded the size of physical memory and there might be some data on swap partition.


Possible solutions
--------------------------
- Build a special undeploy image and use it for either
- Securely erasing the volume on the node side
- Exporting a volume to manager and perform erasing on the manager side
- Create a separate boot configuration on the node that loads a kernel and a ramdisk with undeploy scripts in it

Food For Thought
--------------------------
- Should wiping be a part of deploying or undeploying?
- Should we wipe all nodes or wipe them on-demand?
- Wiping all nodes might be ot required for everyone
- Securely wiping a node requires a lot of time


Related bug report:
https://bugs.launchpad.net/ironic/+bug/1174153

(Session proposed by Roman Prykhodchenko)

Communicating with the nodes:

It would be nice to formalize what and how a node under Ironic's control will communicate with Ironic. Currently the nodes only communication is a signal to start the deploy and return signal that the deploy is completed. Ironic should support a dynamic conversation between itself and the nodes it is controlling.

Ironic will need to support several new areas of communication:
* All node actions
* will need to send basic logging back to Ironic
* should be interruptable
* deployment (if done by an agent on the node)
* nodes will need a way to communicate with Ironic to get the image to be deployed
* Ironic will need to communicate RAID setup and disk partition information to nodes.
* hardware & firmware discovery
* nodes will need a way to send information about their hardware and current firmware revisions to Ironic
* do nodes need to be able (re)discover replaced HW such as a nic?
* firmware update
* Ironic will need a way to push firmware updates to a node
* secure erase
* nodes will need to communicate progress back to Ironic
* Ironic will need to communicate which devices and how many cycles to erase
* burn in
* Nodes performing a "burn-in" will need to communicate any failures back to Ironic
* Ironic will need a way to specify which burn-in tests to run
* Ironic will need to specify how long / how many test to run

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

Open questions:
* Some of the operations above (eg. discovery, RAID setup, firmware) may be performed via multiple vectors (eg, IPMI)
* Some may be best served by borrowing from other OpenStack services (eg, cinder for RAID vol spec)
* Not all deployers will want all of these features, and some may use vendor extensions to accelerate specific features (eg, firmware mgmt). How do we support this mixture?


Etherpad:
https://etherpad.openstack.org/p/IcehouseIronicNodeCommunication

(Session proposed by Chris Krelle)


Thursday November 7, 2013 1:50pm - 2:30pm
AWE Level 2, Room 201A

1:50pm

Nova Un-conference (Thursday)
This session will give an opportunity to cover a variety of topics for 10 minutes each. If you would like to participate, please sign up for a slot on the following etherpad.

https://etherpad.openstack.org/p/NovaIcehouseSummitUnconference

(Session proposed by Russell Bryant)


Thursday November 7, 2013 1:50pm - 2:30pm
AWE Level 2, Room 204-205

1:50pm

Testing Rolling Upgrades
Going forward, OpenStack is going to need to be able to test rolling upgrades, which means multiple versions of services and components interacting with each other under test.

For the project as a whole, this means running with Havana Nova and Icehouse Keystone (for example). From Nova's perspective, this means running scenarios with an Icehouse control plane and Havana compute.

(Session proposed by Dan Smith)


Thursday November 7, 2013 1:50pm - 2:30pm
AWE Level 2, Room 202

1:50pm

Swift operation experiences with hot contents
In KT, we had some experience with swift for the hot contents download situation include
- interacting with the CDN as an origin server
- controlling the buffer cache in the object server
We want to share the experience and suggest some features to improve the performance in such situation.

(Session proposed by Hodong Hwang)


Thursday November 7, 2013 1:50pm - 2:30pm
AWE Level 2, Room 201C

2:40pm

Volume continuous replication
Add the capability for volumes whose data is continuously replicated (i.e., mirrored). This serves as a basis for improved resiliency, HA, and DR.

Session led together with Eric Harney.

https://etherpad.openstack.org/icehouse-cinder-volume-replication

(Session proposed by Avishay Traeger)


Thursday November 7, 2013 2:40pm - 3:20pm
AWE Level 2, Room 201B

2:40pm

Stack abandon and adopt
Blueprint stack-adopt will allow a stack to be created without creating any resources. Instead the state of some existing resources will be passed in to the adopt action. Partnered with blueprint abandon-stack this will allow stacks to be moved from one heat instance to another.

Possible use cases for abandon/adopt are:
* Moving a stack from a private heat orchestrating on a public cloud to the public heat
* Rebalancing a sharded heat
* Moving stacks off a heat that needs an offline upgrade

It also may be possible to hand-craft the resource state so that an adopt can happen on resources which were not previously created with heat.

(Session proposed by Steve Baker)


Thursday November 7, 2013 2:40pm - 3:20pm
AWE Level 2, Room 203

2:40pm

Firmware updates
It's a common requirement that the users or system admins need to update firmware for the baremetal servers, but different vendors may have different processes to do this. The summit is a good opportunity for several vendors to get together and discuss how Ironic may provide a common framework to implement this (may involve the Diskimage-builder project, too).

Etherpad:
https://etherpad.openstack.org/p/IcehouseIronicFirmwareUpdate

(Session proposed by Sun Jing)


Thursday November 7, 2013 2:40pm - 3:20pm
AWE Level 2, Room 201A

2:40pm

Horizontally scalable db backend
Registering this as a Nova session, but it really applies much more broadly.

I'd like to discuss adding an alternative db backend to Nova/Glance/Keystone/etc..

SQLAlchemy offers a diverse set of backends like MySQL, PostgreSQL, sqlite, etc, but none of those meet the needs of a system like OpenStack.

OpenStack needs a horizontally scalable, reliable, failure tolerant data store.

Amazon's seminal Dynamo paper is an inspiration in this space and is the basis for Riak and Cassandra which both seem like very likely backend candidates for this work.

I'd like to suggest using a somewhat backend agnostic approach, so instead of using Riak or Cassandra directly, we could target a well-known API such as AWS SimpleDB or DynamoDB. Client libraries already exist, the data store already exists (in the shape of AWS's own implementations), and its behaviour is well defined and well understood and it's known to scale.

BasicDB, an implementation of Amazon's SimpleDB, recently saw the light of day and a DynamoDB implementation might follow in its tracks, so there's a path towards an entirely free deployment, but the consumer side doesn't need to wait for the server to exist before getting started.

(Session proposed by Soren Hansen)


Thursday November 7, 2013 2:40pm - 3:20pm
AWE Level 2, Room 204-205

2:40pm

Grenade Update
A look at changes and ideas for Grenade and possibilities to use it with non-DevStack deployments

(Session proposed by Dean Troyer)


Thursday November 7, 2013 2:40pm - 3:20pm
AWE Level 2, Room 202

2:40pm

Supporting a global online messaging service
Such as WhatsApp, WeChat, LINE, they serve not only text but also MMS, images, videos, doc, etc.

I think, Swift would fit perfectly for those services, but these kinds of services requirements may differ from VM image serving or similar ones.

For example,
- How Swift(may be Keystone) can support about 1 billion user or permission?

- Most of the objects they serves are not big.

- Support multi-IDC deployments knowhow - object/container/account server?

- Most of objects will be consumed by 1 or small people group.

For those or more requirements, I'd like to discuss about how to design zones&partitions, deploy object/container/account servers & setup replicator & auditor, etc.


(Session proposed by Iryoung Jeong)


Thursday November 7, 2013 2:40pm - 3:20pm
AWE Level 2, Room 201C

3:30pm

More flexible scheduler policies
Currently the scheduler filters in Cinder works in strict manner, which means once a back-end failed to pass any one of the filters, this back-ends looses its chance of being chosen. It'd be useful if we can extend filter scheduler to support 'optional' or 'non-mandatory' filters. Back-ends are not immediately ruled out if they failed to pass optional/non-mandatory filters, instead, they will be considered as sub-optimal candidates and will only be chosen if no optimal back-ends can be found.

Meanwhile, the only weigher we have in Cinder is capacity weigher, which sorts back-ends by free space. This weigher is less useful than it sounds due to that fact that a lot of back-ends may report 'infinite' free space. So it's time to introduce new weighers that utilize more practical metrics as input, for example, allocated volumes, active volumes, active capacity. Since not all the metrics are available on all back-ends, a discussion is worthwhile to clarify the definitions and scope of these new metrics.

(Session proposed by Huang Zhiteng)


Thursday November 7, 2013 3:30pm - 4:10pm
AWE Level 2, Room 201B

3:30pm

Healing and convergence
This session will include the following subject(s):

Healing and convergence:

It may be useful for Heat to have a mechanism for self-healing and/or convergence. i.e., if an underlying resource disappears or goes into an error state for whatever reason, it would be nice for Heat to have a mechanism to fix or delete/recreate the underlying resource, either explicitly through user action ("heat converge") or implicitly (based on a schedule?)

(Session proposed by Christopher Armstrong)

Support API retry function with Idempotency:

I suggest the implementation of retry function as a countermeasure for the failures of API calls to nova, cinder, etc.. when creating/updating a stack in Heat.
In order to avoid the overlapped resource allocations, the proposed retry function supports Idempotency in API calls.
By adding this function, the likelihood of success in creating/updating of the entire stack by one call will be increased.
Please see the following Blue print for more information.


(Session proposed by Takashi Natsume)


Thursday November 7, 2013 3:30pm - 4:10pm
AWE Level 2, Room 203

3:30pm

Making Ironic resilient to failures
The Ironic service must be able to tolerate individual components failing. Large deployments will need redundant API and Conductor instances, and a deployment fabric with no SPoF. Ironic's current resource locking uses the database for lock coordination between multiple Conductors, but only a single Conductor manages a given deployment. There are several things we need to do to improve Ironic's fault tolerance.

Let's get together and plan development of the ways in which we can:
* recover the PXE / TFTP environment for a managed node, when the conductor that deployed it goes away;
* set reasonable timeouts on task_manager mutexes;
* break a task_manager's mutex if the lock-holder is non-responsive or dies;
* distribute deployment workload intelligently among many conductors;
* route RPC requests to the Conductor that has already locked a node;
* route RPC requests appropriately when multiple drivers are used by different Conductor instances.


Etherpad:
https://etherpad.openstack.org/p/IcehouseIronicFaultTolerance

(Session proposed by Devananda)


Thursday November 7, 2013 3:30pm - 4:10pm
AWE Level 2, Room 201A

3:30pm

Nova V3 API
The V3 API is marked as experimental. The discussion would be around what
we need to do to get it to be considered stable enough to be the default
API.

Topics to discuss:
- Enforce access at API level, not DB level
- Cleanup (XML and consistency generally)
- Review of what is core/non-core
- Security related issues
- eg. remove os-personalities?
- what else?
- Remove pagination support?
(see http://summit.openstack.org/cfp/details/6)
- Multiple create support for instance creation
- 207 status
- proper networking support
- Automating spec creation (beyond api samples)
- What level of testing do we need to consider the V3 API to be releasable as the default?

Also maybe something on Pecan/WSME for Nova, but this may be
appropriate in a separate session or included in a more general
pecan/wsme discussion.

(Session proposed by Christopher Yeoh)


Thursday November 7, 2013 3:30pm - 4:10pm
AWE Level 2, Room 204-205

3:30pm

enablement for multiple nodes test
Currently, tempest don't have test cases for the features that require multiple nodes(e.g. migrate, scheduler, filter, availability_zone, etc.). What I have saw is only 'live migration' tests. But it doesn't run in the gate job.

This is a proposal for multiple nodes testing enablement so that tempest can cover the features require multiple nodes in gate job. Some possible discussion about it:
* setup multiple nodes job
* running this job in gate job
* put test cases in scenario tests

(Session proposed by Zhi Kun Liu)


Thursday November 7, 2013 3:30pm - 4:10pm
AWE Level 2, Room 202

3:30pm

Making Swift More Robust to Handling Failure
I would like to take some time to focus on some areas that could make swift more robust to failure scenarios. This will may include discussions about (but not limited to):

1. Better error limiting. The error limiting code has gotten a bit stale, and could use an audit and cleaning up. On top of that, the level of audit is at the worker level, so if you have a machine with many workers, it can take a while before a node gets completely error limited. It might be useful to have a local cache that is shared across the workers.

2. Early return on writes. Currently, the elapsed time for a write will be the slowest of the 3 replica writes. In the case that you have a badly behaving node, can cause a lot of issues. We should be able to return to the user as soon as 2 replicas have been successfully written

3. Async fsync. It might be useful to have an optional setting that would allow an object server to return immediately upon the completion of the write, and issue the fsync asynchronously. This of course comes at a risk, but I would like to discuss ways to possibly mitigate this.

There are other smaller things as well, and I would be curious to hear other ideas how we can make swift more robust.

(Session proposed by creiht)


Thursday November 7, 2013 3:30pm - 4:10pm
AWE Level 2, Room 201C

4:10pm

Break
Thursday November 7, 2013 4:10pm - 4:30pm
OpenStack Quad

4:30pm

Heat support for multi-region and multi-cloud
Let's talk on how should Heat support multi-region (two separated OpenStack installation) and multi-cloud (common orchestration tool for public and private clouds) environments.

"Right now Heat can orchestrate only one OpenStack installation (one region). We would like to use Heat to create/update and delete resources in different regions using one template file. It means that it should be possible to specify in template file for each resource in which region we want to create it. Heat engine should parse multi region template and create all specified resources accordingly with dependencies."


Wikipage:
https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat

Past discussion on ML:
http://lists.openstack.org/pipermail/openstack-dev/2013-July/012305.html

(Session proposed by Bartosz Górski)


Thursday November 7, 2013 4:30pm - 5:10pm
AWE Level 2, Room 203

4:30pm

Requirements project redux
Now that we have gotten through a cycle with the requirements project we should discuss what worked, what didnt work, and how things can be improved.

(Session proposed by Chuck Short)


Thursday November 7, 2013 4:30pm - 5:10pm
AWE Level 2, Room 202

4:30pm

Disk and Volume management in Ironic
Let's talk about how Ironic can manage local ephemeral, local persistent, and network-attached storage in a general way, and then make a plan to implement it!

Some things to consider:
* TripleO requires local volumes that persist across re-imaging of the machine, eg. "nova rebuild";
* Users may require secure-erase of all local volumes on instance deletion;
* Flavor "root_gb" may be much less than actual storage; use of the additional space should be enabled via Cinder and Ironic APIs;
* Users may request different RAID topology be applied to the same node;
* Some hardware can mount a network volume and present it as a local disk;


Etherpad:
https://etherpad.openstack.org/p/IcehouseIronicVolumes

Related Bugs:
https://bugs.launchpad.net/ironic/+bug/1174153
https://bugs.launchpad.net/ironic/+bug/1238311


(Session proposed by Devananda)


Thursday November 7, 2013 4:30pm - 5:10pm
AWE Level 2, Room 201A

4:30pm

Federated Identity
Note: This is part 1 of a 2 part session. Part 2 will take place in the same room after a short break.

https://etherpad.openstack.org/p/icehouse-federation

It seems there are some blueprints, and corresponding wikis that try and flesh out a design for federated identity support in keystone. Currently neither exist in OpenStack.

Let's go through the use cases, the two different approaches that have been proposed (Joe Savak @ Rackspace and David Chadwick @ University of Kent), and the primary concepts and technologies (IDPs, mapping and SAML, authentication).

1) Use Cases can be found here:
https://etherpad.openstack.org/p/federation-flows

2) Concepts:
a) IDPs
b) Federation mechanism: SAML, ABFAB, OAuth
c) Attribute mapping
d) Authentication requests

3) The two different approaches:
Joe Savak @ Rackspace
bp: https://blueprints.launchpad.net/keystone/+spec/virtual-idp
wiki: https://wiki.openstack.org/wiki/Keystone_Virtual_Identity_Providers
api-spec: https://review.openstack.org/#/c/51980/

David Chadwick @ University of Kent
bp: https://blueprints.launchpad.net/keystone/+spec/federation
wiki: https://wiki.openstack.org/wiki/Keystone/Federation/Blueprint
api-spec: https://review.openstack.org/#/c/39499/

The goal for this session is to decide on one approach for keystone to pursue supporting during Icehouse.

Discussion here: https://etherpad.openstack.org/keystone-federation and here: https://etherpad.openstack.org/p/federation-flows

(Session proposed by Steve Martinelli)


Thursday November 7, 2013 4:30pm - 5:10pm
AWE Level 2, Room 201B

4:30pm

Using Pecan/WSME for the Nova V3 API
This session will include the following subject(s):

Using Pecan/WSME for the Nova V3 API:

A discussion around whether we should replace wsgi with Pecan/WSGI for the V3 API. And if so, how can we do this without the level of disruption that occurred with the initial V3 work done in Havana.

Note that I think this discussion would be a lot more productive if it was scheduled some time after the proposed oslo session "Creating REST services with Pecan/WSME"

http://summit.openstack.org/cfp/details/154

(Session proposed by Christopher Yeoh)

API validation for the Nova v3 API:

32% of Nova v3 API parameters are not validated with any ways[1].
If some clients just send an invalid request, an internal error happens and OpenStack operators should research its reason.
It would be hard work for the operators.

For Nova v3 API, WSGI will be replaced with Pecan/WSME. and some relational sessions have been proposed.
We'd better to implement basic validation features on WSME if we need more features.

Now some basic features are proposed[2], and I hope we make a consensus about this features and discuss how to implement them.

This session is related to "Using Pecan/WSME for the Nova V3 API" session(http://summit.openstack.org/cfp/details/165).
It is better to schedule this after "Using Pecan/WSME for the Nova V3 API" session or merge this into it.

[1]: https://wiki.openstack.org/wiki/NovaApiValidationFramework
[2]: http://lists.openstack.org/pipermail/openstack-dev/2013-October/016635.html


(Session proposed by Ken'ichi Ohmichi)


Thursday November 7, 2013 4:30pm - 5:10pm
AWE Level 2, Room 204-205

4:30pm

Metadata Search
We at HP Storage have created an Object Storage Metadata Search (OSMS) REST API that we would like to present to the Swift community for an open discussion. We have started an implementation that uses HP StoreAll's existing Express Query NoSQL database to store account, container, and object metadata for subsequent complex query functionality. It is similar in intent to SoftLayer's "API Operations for Search Services" (http://sldn.softlayer.com/article/API-Operations-Search-Services) but more feature-rich. It does not involve any changes to OpenStack code except for Swift middleware. We are interested in leading a pure OpenStack specification and implementation, as a standard extension to Swift. We're encouraging any community effort to move this forward, including SoftLayer developers. We have no reference implementation nor design that is pure OpenStack yet. We are just getting the conversation started. We will present the API we've designed so far, as a strawman for discussion, extending the base Swift REST API (http://docs.openstack.org/api/openstack-object-storage/1.0/content).


(Session proposed by Lincoln Thomas)


Thursday November 7, 2013 4:30pm - 5:10pm
AWE Level 2, Room 201C

5:20pm

Heat placeholder session
TBA, a session to cover the topics that need further discussion.

These may include:
* additions to REST API, v2 or extensions
* follow-up further HOT software configuration discussions

(Session proposed by Steve Baker)


Thursday November 7, 2013 5:20pm - 6:00pm
AWE Level 2, Room 203

5:20pm

Preemptively Integrate the Universe
We are currently doing preemptive integration on all the openstack projects needed to run an OpenStack cloud. But we depend on a hundred upstream python packages, which have very mixed track records on their ability to upgrade smoothly. This creates problems all the time during the release, and two weeks of hell right before pycon, as everyone pushes out new major versions.

We can do better.

I'd like to come up for a plan of attack to preemptively integrate the world. Starting with all the python libraries that have moved to stackforge, and expanding to any upstream library that we've had issues with in the past. For non stackforge things this wouldn't be gating, but be informative, and help us understand when problems are coming, and hopefully let us catch bugs in upstream packages before they hit released versions.

(Session proposed by Sean Dague)


Thursday November 7, 2013 5:20pm - 6:00pm
AWE Level 2, Room 202

5:20pm

Ironic's Next Steps
Let's discuss what remains to be done before we can tag our first RC and tell everyone to migrate away from nova-baremetal. Since this will be our last session for the day, we should also list the various tasks that we've postponed, and discuss anything that isn't clear.

I would also like to specifically invite vendors and anyone deploying nova-baremetal to this session. Their feedback will be invaluable in helping the project evolve to meet the needs of the community.

Expect a lively session and many action items getting assigned to NobodyCam before we're done!


Etherpad: http://etherpad.openstack.org/IcehouseIronicNextSteps

(Session proposed by Devananda)


Thursday November 7, 2013 5:20pm - 6:00pm
AWE Level 2, Room 201A

5:20pm

Federated Identity (Cont.)
https://etherpad.openstack.org/p/icehouse-federation

This is a simply a continuation of the previous Federated Identity session, in the same room.

(Session proposed by Dolph Mathews)


Thursday November 7, 2013 5:20pm - 6:00pm
AWE Level 2, Room 201B

5:20pm

Cross project request ids
With tempest now running tests in parallel it has become a lot more difficult to debug failures because request ids are project specific and timestamps can not be reliably used because of the number of tests running at the same time. Request ids which cross service boundaries would make debugging test failures in the gate much easier.

Some work was done during Havana to implement this but it currently appears stalled due to some security concerns. See

https://review.openstack.org/#/c/29342
https://review.openstack.org/#/c/29480

I think a session would really help find a solution to these concerns.

(Session proposed by Christopher Yeoh)


Thursday November 7, 2013 5:20pm - 6:00pm
AWE Level 2, Room 204-205

5:20pm

Why is Swift's replica count configurable?
So you can change it! 4 replica clusters are the bee's knees - or are they?

In preparation for this session I will simulate failures on multi-node Swift deployments running 2, 3 and 4 replica rings and see where things break. I'd like to crunch some numbers and get laughed at for my naive arithmetic while attempting to explain how Swift's quorum calculation affect durability and availability when using different replica counts.

The goal of this session would be a public documentation of the current expected behavior which we can point to in defense when triaging bugs like "I have a two disk, two replica swift and if I unplug it I can't upload my lolcats".

I'm also open to the possibility of learning where it might make sense to propose changes (or a more tunable configuration - if there is no single obviously correct behavior) for valid use-cases that the Swift community *wants* to support. So I'll need you to come prepared to tell me what we think is reasonable.

(Session proposed by Clay Gerrard)


Thursday November 7, 2013 5:20pm - 6:00pm
AWE Level 2, Room 201C
 
Friday, November 8
 

9:00am

API documentation repos
Diane Fleming is working on a blueprint for the continuous improvement of our API docs to help out end-users.

The API docs consist of 1) The API Reference pages, 2) The docs generated from the project-api repos, such as http://docs.openstack.org/api/openstack-compute/2/content/.

I am setting up this session to find out how you use (and would like to use) the project-api repos.

(Session proposed by Anne Gentle)


Friday November 8, 2013 9:00am - 9:40am
AWE Level 2, Room 201B

9:00am

Heat exorcism
The nice thing about the CloudFormation template format is that it contains no magic whatsoever. The 'Ref' function returns a string reference to a resource ID that is the same string that you might use to identify the resource if you were calling an API directly. You can pass these strings e.g. between templates or as parameters based on pre-existing resources you have created yourself and everything behaves exactly as it should.

Heat, on the other hand, is full of magical hacks cobbled together in such as way that they are completely invisible to the user until they hit a case that doesn't work. A probably-incomplete list:

* AutoscalingGroup resources can use a LaunchConfiguration only if it is created in the same stack.
* ScalingPolicies work only with AutoscalingGroups created in the same stack.
* AccessKeys can reference only a User created in the same stack.
* User resources access their associated Policies by looking up the RefId of the policy by name(!) in the same stack.
* Neutron Ports can reference only SecurityGroups created in the same stack.
* Neutron RouterGateways have hidden dependencies on RouterInterfaces and Subnets, but only if they are defined in the same stack. This means things may not work if they are defined in different stacks, and dependencies are impossible to debug as they are hidden from the user.
* Neutron Ports have similar hidden dependencies on Subnets.
* WaitConditions must be defined in the same stack as their WaitConditionHandles.
* AutoscalingGroup resources can use a LoadBalancer only if it is created in the same stack.
* The CeilometerAlarm resource uses a magic automatic reference to an action in the same stack if the user passes a resource name instead of using Fn::GetAtt to retrieve the AlarmUrl attribute.

We need to exorcise the magic from Heat. There are a number of different strategies we may want to use to attack different parts of the problem.

Most of the issues relate to 'resources' that have no actual underlying physical resource (with a UUID, and API &c.) outside of Heat. We need a way of accessing these without needing to spread authentication code (which is currently confined to the API middleware) throughout the engine.

In the case of Neutron, the problem is a bad API design that was only discovered after we had implemented resources. IMO it is a mistake to tie the resource design to mirror exactly the current API, since new API versions are released regularly. We should consider redesigning the resources with the primary criterion that they actually work, and fidelity to a particular version of the underlying API well down the list.

(Session proposed by Zane Bitter)


Friday November 8, 2013 9:00am - 9:40am
AWE Level 2, Room 203

9:00am

Proposed Features and API Changes
In this session we'll discuss several potential features and API changes based on customer feedback gathered by HP.

Topics:

* Message queuing vs. retrieval by ID
* Binary message bodies
* Cross-project access control, ACLs
* Message claiming and acknowledgement
* Atomic message batching

(Session proposed by Hong Yuan)


Friday November 8, 2013 9:00am - 9:40am
AWE Level 2, Room 201A

9:00am

Resource Management
In this split session we'll be discussing scheduling and resource management.

This session will include the following subject(s):

Service VMs & HW devices, scheduling and agents:

This session is proposed to discuss how virtual or physical appliances can better be supported in Neutron. Focus is on scheduling, network plugging, and evolution of agents.

These are pretty much all topics that could be covered in discussions of framework for service VMs. Hence, this proposal could be merged with other session proposals to get a workable session schedule.

(Session proposed by Bob Melander)

Dynamic Network Resource Management for Neutron:

DNRM is a framework which adds virtual network appliance support, multivendor network resources, and policy-based scheduling of physical and virtual resource instances. It overlaps several other initiatives, including proposals for service instances. We will be demonstrating a prototype implementation during the Summit. The goal of this session is to transform this blueprint into a work item for Icehouse.

(Session proposed by Geoff Arnold)


Friday November 8, 2013 9:00am - 9:40am
AWE Level 2, Room 201C

9:00am

VMWare Driver Roadmap For Icehouse
Areas where we would like to improve the VMWare Driver for nova. This includes

* Scheduler enhancements such as
* Supporting local storage
* Image aware scheduling
* Improving live migrations
* Adding awareness of the topology of the host aggregate

* Nova snapshots
* Handing multiple files that result in a snapshot
* Handling attached volumes

* Running with multiple nova-compute agents

Misc improvements
* Hot-plug NICs
* VM Pause/Resume
* VNC password per VM
* Improve unit test coverage
* Move to mock from mox

Please see the etherpad for more details - https://etherpad.openstack.org/p/T4tQMQf5uS

(Session proposed by Tracy Jones)


Friday November 8, 2013 9:00am - 9:40am
AWE Level 2, Room 204-205

9:00am

Python3 and Pypy support
In havana, we started adding python3 support and we made a start with the infrastructure of what needs to be done. What do we need to do in Icehouse to continue with that effort ?

In parallel there were efforts to support running OpenStack under Pypy. We'll review the status of that effort as well and the next steps for the Icehouse cycle.

(Session proposed by Chuck Short)


Friday November 8, 2013 9:00am - 9:40am
AWE Level 2, Room 202

9:50am

Stack troubleshooting support
Problem determination for template deployment is currently limited to logging. The user can set different level of verbosity in the log and typically has to rerun the deployment multiple times to debug the problems. Based on our experience with template development and debugging, as well as feedback from customers, we propose employing the concept of live debugger that is common in software development. A template, e.g. HOT, would be treated at a program, and the user can use the debugger to break into the deployment at the point of error or other points to inspect the partial stack, resources, environment, scripts, etc. During the debugging session, the deployment would be paused and the user can control the execution with single stepping, resuming, etc. User can enter the debugger by different methods: (1) break on error, (2) set breakpoints, (3) attach to a template being deployed.
The declarative nature of HOT and the concurrent deployment do present some challenges, making the debugger somewhat different from a typical program debugger. We also want to handle activation (cloud-init, cfn-init) and configuration managers used in the template (Chef, Puppet) in a seamless manner as if they are part of the template.

Heat can greatly reduce the amount of work cloud administrator has to deal with if everything goes well. However, things can get quite complicated when the automation process fails at some point. Users of Heat have to login every VMs (could be many) to figure what went wrong by examing the cloud-init and tools logs. So a way to retrieve the cloud-init and tools logs to let users to exam conveniently is desired, which is what this proposal tries to address.

(Session proposed by Thoms Spatzier)


Friday November 8, 2013 9:50am - 10:30am
AWE Level 2, Room 203

9:50am

Notification Service Extensions for Marconi
Marconi already supports the publish-subscribe messaging pattern, but a true notification system also implies subscriptions to discoverable topics, and multiple options for message delivery.

Let's discuss how these capabilities relate to and/or extend the Marconi code base.

Goals:

* Understand the use cases and requirements for a cloud notifications service.
* Get a rough idea of how a notifications service would use or extend Marconi queues.


(Session proposed by Muharem Hrnjadovic)


Friday November 8, 2013 9:50am - 10:30am
AWE Level 2, Room 201A

9:50am

Neutron based Distributed Virtual Router
The aim of this session is to discuss about implementing a Distributed Virtual Router in Neutron.

Distributed Virtual Routing
---------------------------
Today Neutron supports L3 Routing functionality in the Network Node. So for any Intra Tenant routing, the packets have to flow through the Network Node which creates a single point of failure.
Also it introduces performance issues.

Distributed Virtual Router will provide flexibility to add routers within the compute node and route packets locally instead of passing through the Network Node.

The goals of this session would be:
1. To get consensus from the community on the right model for the Distributed Virtual Router with the proposed one.
2. Provide a roadmap for this feature support.
3. Identify any dependencies.
4. Next steps ( Define and refine any extra API's required, plugins to use either use the existing L3Plugin or write an extension) etc.,


--Blueprint Links TBA



(Session proposed by Swaminathan Vasudevan)


Friday November 8, 2013 9:50am - 10:30am
AWE Level 2, Room 201C

9:50am

libvirt driver roadmap
This session is for those interested in discussing new development for the libvirt compute driver.

(Session proposed by Russell Bryant)


Friday November 8, 2013 9:50am - 10:30am
AWE Level 2, Room 204-205

9:50am

Writing a service synchronisation library
In Ceilometer, we have a few services that needs their daemons/agents to be synchronized and to have work split among them. That includes the alarm evaluator, or the evolution we'd like to have on the central agent.

Some services like Nova uses part of this mechanism in the "servicegroup" implementation.

We think that a lot of services in OpenStack could use such a functionality, so having a common solution into Oslo would be a nice solution.

(Session proposed by Julien Danjou)


Friday November 8, 2013 9:50am - 10:30am
AWE Level 2, Room 201B

9:50am

Release artifact management
We need to discuss when, how and where we upload release artifacts. Specifically:

- should we upload server releases to pypi
- how should client lib releases work
- how does this interface with storyboard
- what about if we had a non-python thing?

(Session proposed by Monty Taylor)


Friday November 8, 2013 9:50am - 10:30am
AWE Level 2, Room 202

10:30am

Break
Friday November 8, 2013 10:30am - 11:00am
OpenStack Quad

11:00am

What's next for taskflow in cinder
I would like to discuss with the cinder folks the initial work done in cinder with regards to taskflow and get some of there initial feedback as well as explore and discuss future work (and features) that can be done with the integration with cinder & taskflow.

(Session proposed by Joshua Harlow)


Friday November 8, 2013 11:00am - 11:40am
AWE Level 2, Room 203

11:00am

AMQP and SQL backends
Come and join us as we discuss plans for additional back-end storage drivers in Marconi. We'll go over what is required to support AMQP-based brokers (and whether is really makes sense), and talk about the work to support SQL databases. If time allows, we'll also discuss support for other back-end drivers (whether as part of Marconi itself, or offered by third parties).

Goals:

* Understand use cases and API implications re an AMQP driver
* Achieve a rough consensus on whether an AMQP driver is worth pursuing in the next 6-12 months
* Get feedback on the design of the SQL driver
* Make a list of next steps re backend drivers

(Session proposed by Flavio Percoco Premoli)


Friday November 8, 2013 11:00am - 11:40am
AWE Level 2, Room 201A

11:00am

Neutron Service Chaining and Insertion
We have three "advanced" services in Neutron today, LBaaS, FWaaS, and VPN. However, there is no API available to the user to express as to which traffic to subject these services to. For instance, a bump-in-the-wire firewall, or a tap service, or a L2 VPN would all require a subnet context. When provided, this context can be used by the provider to appropriately configure the data path and is commonly referred to as service insertion.

Moreover, with more than one service, it becomes relevant to explore the model of how multiple services can be sequenced in a chain. An example, in the context of today’s reference implementations, is the insertion and chaining of firewall and VPN services. Each of these reference implementations rely on the use of IPTable chains to program the relevant filters and policies to achieve their respective purposes. However, in the absence of a chaining abstraction to express the sequence of these services, these implementations act independently and the resulting order of operations is incidental and cannot be controlled.

In this session we will discuss how the above two issues can be solved by enhancing existing abstractions and augmenting with new abstractions in Neutron. The objective will be to support both modes of instantiating services - independently, and as a part of a chain - with support for the former in a non-disruptive fashion (since this is the default mode today).

There was discussion on this topic during the last summit. The proposed session will advance this discussion based on the feedback gained during the past six months (and build on what was added to Neutron in the H release). We will focus on transitioning to the pragmatics of what can be implemented and achieved in the Icehouse timeframe.

Etherpad: https://etherpad.openstack.org/icehouse-neutron-service-insertion-chaining

(Session proposed by Sumit Naiksatam)


Friday November 8, 2013 11:00am - 11:40am
AWE Level 2, Room 201C

11:00am

Docker support in OpenStack
Let's discuss how Docker support can be improved in OpenStack. Especially in Nova. Starting with the Havana release, there is a Docker driver that allows Nova to deploy instances using Docker containers.

(Session proposed by Sam Alba)


Friday November 8, 2013 11:00am - 11:40am
AWE Level 2, Room 204-205

11:00am

Oslo incubated libraries status
This session will include the following subject(s):

Oslo incubated libraries status:

What state are the various incubated libraries in, and which are close to being ready to move out of the incubator?

(Session proposed by Doug Hellmann)

Taskflow & oslo:

I would like to talk with the oslo focus to discuss the work done in taskflow, its goals, its current progress & integration and to see how we can align to fit into taskflow+oslo (if such a thing is possible) so that taskflow and oslo can be happily married and live happily ever after (it's a metaphor).

Taskflow wiki (with mission, examples)...

- https://wiki.openstack.org/wiki/TaskFlow

Code:

- https://github.com/stackforge/taskflow

(Session proposed by Joshua Harlow)


Friday November 8, 2013 11:00am - 11:40am
AWE Level 2, Room 201B

11:00am

Keystone needs on the QA Pipeline
Keystone has recently started pushing tests for the Keystone client toward Tempest. Without using Tempest, Keystone client tests cannot be run against a live server.

This session will be used as an exploration of the approaches that Keystone currently has to testing with Tempest, ideas the Keystone team has in integrating in new ways with the QA pipeline, and exploring holes that exist today with coverage of Keystone, and make sure we harmonize approaches being taken by both the Keystone and QA teams.

The expected output is a set of things to help ensure solid Keystone coverage in the QA pipeline in Icehouse.

(Session proposed by Adam Young)


Friday November 8, 2013 11:00am - 11:40am
AWE Level 2, Room 202

11:50am

Exception clarity and how rescheduling affects u!
While integrating taskflow with cinder there was a need to maintain backwards compataiblity with the exception model that existed for rescheduling in cinder. Now that the code has been shifted into an area where it is easily identifable what will and will not cause an exception we should start to think about other ways of how to deal with exceptions in cinder.

It would be nice to discuss the exception model and possibly discuss how we can make the exception model easier to use and more resilent to badly behaving drivers.

(Session proposed by Joshua Harlow)


Friday November 8, 2013 11:50am - 12:30pm
AWE Level 2, Room 203

11:50am

Marconi for Icehouse: What's in, What's out
Come join the discussion as we lay the plans for Marconi graduation into OpenStack, and finalize the features and changes for the Icehouse release. This session will be the final Marconi design summit session of the day, so we'll incorporate the decisions made in earlier sessions and lay plans for the next few months.

Goals:

* Decide on a core set of "essentials" that need to be done in time to graduate for Icehouse.
* Decide on some "nice-to-haves" that we can work on for Icehouse if we have time, and if not, that we can target for the first post-Icehouse milestone.
* Decide whether a bump in the API version and/or any extensions are in scope for Icehouse (if we have time)

(Session proposed by Allan Metts)


Friday November 8, 2013 11:50am - 12:30pm
AWE Level 2, Room 201A

11:50am

Layer 2 Topics
This session will include the following subject(s):

L2 VPNs as a service:

This is a discussion of L2 VPNs, such as GRE tunnels L2TP, and even VLANs, and how we might implement an API for them in Neutron.

L2 VPNs are different from L3 VPNs in that there is no address on the inside end of the connection, the end which transmits content between the tunnel and the Neutron network. In some encap cases, such as VLANs, there isn't even an IP address on the outside of the tunnel.

There are API models we already use have some parallels to L2 VPNs - both routers and provider networks have some similarities - but neither is a perfect match. Routers typically provide an addressed internal port and provider networks are statically created by config as they relate to the hardware setup of the system.

This session will review a few possible models for how we might describe L2 VPNs with objects and REST APIs, followed by a general discussion.

(Session proposed by Ian Wells)

Gateway extension API proposal:

Abstract:

Neutron already provides an abstract Router API extension for routing between cloud tenants virtual networks. Its main useful purpose is to enable NATing of IP addresses of the unlimited number of VMs to a limited pool of external/public IPv4 addresses. However, routing between virtual networks subnets adds some complexity (at least for the simple tenant abstract API) in automating the mandatory /subnet IP subnet address design of virtual networks belonging to the same tenant, in sharing various L2 services (usually by configuring helper services in routers), and in moving VMs with zero downtime (usually with extra tunneling if not in the same L2).

We propose to add optional Bridging operations to the Router object so that we abstract both Router and Bridge in a Gateway object managed by Cloud Tenants Admins. This will provide a simple REST interface to bridge virtual networks together and with physical networks while the underlying plugin will focus on programmatically controlling the L2 broadcast regardless of all the heterogeneous virtual networking technologies. This broadcast is usually emulated using L2oL3 tunnels overlays between virtual switches if native tagging is not provided, but other schemes could also be used. With this API, we will be able to easily stitch Neutron Networks to benefit from various existent services in enterprise data centers that are not managed by OpenStack:
enterprise DHCP servers, PXE boot software provisioning servers, L2VPN gateways to elastic WANs, to only cite few.



(Session proposed by Racha Ben Ali)


Friday November 8, 2013 11:50am - 12:30pm
AWE Level 2, Room 201C

11:50am

XenAPI Roadmap for Icehouse
Get to together and set priorities for the icehouse work on the XenServer support.

Including things like:
* gating tests for XenServer
* Review any hypervisor support gaps
* using/building supported interfaces
* Live-migrate based Resize (remove dependency on rsync)
* PCI passthrough
* Support for virtual GPUs
* Supporting LVM based storage
* Local storage volumes

For details see:
https://etherpad.openstack.org/IcehouseXenAPIRoadmap

(Session proposed by John Garbutt)


Friday November 8, 2013 11:50am - 12:30pm
AWE Level 2, Room 204-205

11:50am

Aggressively split oslo-incubator
We should think about splitting all of the modules in oslo-incubator into different repos from the start. This doesn't mean an end to incubation copying, but rather a different approach. The update.py tooling would have to change - but as a benefit, it would let us better model the oslo-core+%(module)s-core structure early on.

(Session proposed by Monty Taylor)


Friday November 8, 2013 11:50am - 12:30pm
AWE Level 2, Room 201B

11:50am

Coverage analysis tooling
Back in the grizzly cycle the coverage extension for nova was introduced. It created an api to enable coverage collection and reporting for external programs on a running nova installation. A client script was added to tempest to use the extension and a periodic nightly run was setup to watch the coverage. However, the extension and the tooling to use it haven't been used much and we often fall back to manual inspection when we try to figure out testing coverage.

This session would be dedicated to figuring out exactly what kind of tooling is needed so that we can classify and improve tempest test coverage an enable other test suites to figure out coverage easily. Also, any other steps that could be used to increase automation of coverage analysis and improving the usefulness of the data. Some possible topics for discussion for this session could be:
* Improving or reworking existing coverage extension
* Adding a coverage extension to each project
* Additional tooling around coverage collection and analysis
* Running coverage on each gate run

(Session proposed by Matthew Treinish)


Friday November 8, 2013 11:50am - 12:30pm
AWE Level 2, Room 202

12:30pm

Lunch
Friday November 8, 2013 12:30pm - 1:30pm
OpenStack Quad

1:30pm

Vendor neutral extra_specs
In the last we've failed to agree on some extra_specs that work for ALL storage vendors. I'd like to propose some ideas that I think could be implemented universally, and I'd like to avoid ratholes this time around.

(Session proposed by Ben Swartzlander)


Friday November 8, 2013 1:30pm - 2:10pm
AWE Level 2, Room 203

1:30pm

Token revocation
https://etherpad.openstack.org/p/icehouse-token-revocation

A token may not be expired yet, but the authorization it presents may no longer be valid.

As a result, keystoneclient.middleware.auth_token constantly needs to ask "Is this token valid?" We've taken a couple different approaches to answering this question in the past, including:

- UUID tokens + online token validation
- PKI tokens + periodically fetching a list of revoked tokens

Both existing solutions require keystone to track issued tokens so that it can later know which to consider as "revoked," and both solutions result in an undesirable amount of network traffic and activity against the token backend.

I'd like to select and pursue a better approach (if any) to avoid the pitfalls described above. Proposed solutions include:

https://blueprints.launchpad.net/keystone/+spec/clock-for-revoke-tokens
https://blueprints.launchpad.net/keystone/+spec/revocation-events

(Session proposed by Dolph Mathews)


Friday November 8, 2013 1:30pm - 2:10pm
AWE Level 2, Room 201B

1:30pm

ML2 SDN Mechanism Drivers and Agents
This session will include the following subject(s):

Neutron+SDN: ML2 MechanismDriver or Plugin?:

The Modular Layer 2 (ML2) core plugin introduced in havana replaces and deprecates the monolithic Open vSwitch and Linux Bridge core plugins. It includes MechanismDrivers supporting both of these plugins' L2 agents as well as the Hyper-V L2 agent. Not only is redundant code eliminated, but these L2 agents can now be combined in heterogeneous environments. Additional MechanismDrivers integrate with various types of switching gear. The ML2 MechanismDriver API is intended to support integration with any type of virtual networking mechanism, and work is under way to integrate at least one SDN controller via ML2.

This session will explore the two approaches for integrating SDN controllers with neutron - as monolithic core plugins and as ML2 MechanismDrivers. Topics to discuss include any current technical obstacles to integrating SDN controllers via ML2, advantages of using ML2, and whether the heterogeneity provided by ML2 is useful with SDN. Hopefully the session will lead to consensus on which approach makes more sense for future SDN integrations, and whether current core plugins supporting SDN controllers should eventually become ML2 MechanismDrivers. It will be of most value if maintainers of existing monolithic plugins and ML2 MechanismDrivers, as well as those considering new ones, can participate.

(Session proposed by Robert Kukura)

Modular [L2] Agent:

We now have a Modular Layer 2 (ML2) core plugin that supports a variety of networking mechanisms. Many of those involve L2 agents. These agents typically have similar structure and code. Can they be replaced by a single modular L2 agent? If so, can/should that agent support other functionality beyond L2 (L3, DHCP, *aaS, ...)?


(Session proposed by Robert Kukura)


Friday November 8, 2013 1:30pm - 2:10pm
AWE Level 2, Room 201C

1:30pm

Nova Un-conference (Friday)
This session will give an opportunity to cover a variety of topics for 10 minutes each. If you would like to participate, please sign up for a slot on the following etherpad.

https://etherpad.openstack.org/p/NovaIcehouseSummitUnconference

(Session proposed by Russell Bryant)


Friday November 8, 2013 1:30pm - 2:10pm
AWE Level 2, Room 204-205

1:30pm

Future of Scenario testing
We've discussed scenario testing in Havana summit, as a result, that was introduced into Tempest.
In this session, we'll discuss the status of the implementation, missing testcases, documents and tools for increasing the coverage of the scenario testing.

The discussion points:
* The status of the scenario test cases
* What scenario test cases do we need to implement?
* Documents for implementing scenario tests cases
* Tools and/or frameworks for easy to add scenario test cases.


(Session proposed by Masayuki Igawa)


Friday November 8, 2013 1:30pm - 2:10pm
AWE Level 2, Room 202

1:30pm

Networking and installation topologies
Etherpad: https://etherpad.openstack.org/p/savanna-icehouse-networking

This session will include the following subject(s):

Handling the one-public-ip-per-cluster use case:

As the Hadoop clusters that Savanna manages grow having a floating/routable IP for each instance is not only wasteful but often unnecessary.

In a typical deployment the head node(s) (JobTracker&NameNode) need to be accessible to the user, but the individual workers within the cluster must only be accessible from the head node.

There is an architecture discussion to have about how to support this use case.

(Session proposed by Matthew Farrellee)

Flexible networking support:

Discuss the mechanisms required to support both nova-network and Neutron including features that could be required in area of networking for Savanna.

Subtopics:

* networking in different OpenStack topologies (problem of accessing VMs from Savanna controller and etc.);
* provisioning of a cluster over a private network/namespace using Neutron.

(Session proposed by Jonathan Maron)


Friday November 8, 2013 1:30pm - 2:10pm
AWE Level 2, Room 201A

2:20pm

Access Control List Rule for Cinder Volumes
ACL implementation is a mechanism of permission management.
Currently only one type of permission is available: full access for the owner, no access for other users or tenants.

Purpose of ACL: make different volume access permissions possible.

Why useful?
1) Granting different access permissions to volumes, which can establish a foundation for volume transfer, read-only volumes (more flexible, than implemented in havana), public volumes, etc.
2) The owner of the volume and the administrators always have the full access and can assign the permission to other users or group of users.

Some use cases
1) as a foundation for read-only volumes (with flexible configuration, currently only 2 options are available: R/O for everyone or R/W for everyone)

Owner or Admin would be able to grant R/O access for the another user (or for users in a user group, or for a tenant, or everyone).

2) as a foundation for public(i.e. cross-tenant visible) volumes (currently Volume is visible for all the users from the only tenant)

Owner or Admin, or someone with the sufficient access level would be able to make a volume visible for all the tenants just by setting some access permission for "everyone" project.

Proposal to discuss
1) Remaking havana's ACL design to embrace foundations for read only and public volumes
2) Changing a representation of permission levels (in order to easy an aggregation of some access permissions in case if User in some groups with different access permissions e.g.)

(Session proposed by Anastasia Guzikova)


Friday November 8, 2013 2:20pm - 3:00pm
AWE Level 2, Room 203

2:20pm

OAuth, Trusts and Delegation
https://etherpad.openstack.org/p/icehouse-delegation

In the havana release, we added OAuth 1.0a support to keystone; I received a lot of suggestions to enhance this feature. The point of this session is to vet those suggestions and gauge participant interest.

Another goal of the session is a two-parter, 1) Quickly establish the differences between oauth and trusts for the crowd. And 2) See if there are any other delegation models, or a way to wrap oauth and trusts, so they are not completely different code paths.

Future OAuth work suggestions:
- Changing the token secret to be a hash of information, rather than just uuid. Dolphm already has a prototype working. The point of this is that it could be used offline.
- Adding a web UI, pretty self-explanatory, this would make using the oauth delegation mechanism much easier. Would this go directly into horizon? Or can this exist in keystone?
- Using policy config files to assert delegation. ayoung suggested that if we let Keystone parse the policy config files it is handed. Keystone would then be able to deduce what a give token would be allowed to do. THen, instead of delegating a whole a role, a user could delegate the ability to execute individual api functions. Then, a token could say: only let the bearer execute function X on Nova.
- Moving to a newer and better library, oauthlib. Near the end of the release, there were some concerns brought up about the current library being used.

(Session proposed by Steve Martinelli)


Friday November 8, 2013 2:20pm - 3:00pm
AWE Level 2, Room 201B

2:20pm

Neutron L3 Agent improvements
This session will explore how we could improve the Neutron L3 Agent by bringing high availability and stateful connections for external network connections.

The discussion will be about API design, scheduling and which backends to use (keepalived, ipvs, etc).

(Session proposed by Emilien Macchi)


Friday November 8, 2013 2:20pm - 3:00pm
AWE Level 2, Room 201C

2:20pm

Work in IceHouse around nova DB
This session will include the following subject(s):

Work in IceHouse around nova DB:

We done a lot of work in Havana around DB in whole OpenStack and especially Nova. I don't see any reason to stop continue improving it.


Nova is also favorite in DB related things, so it will be nice to discuss next points:
1) Use oslo.db lib

2) Switch from sqla-migrate to alembic
(we found already one approach that allows us to make this all without rewritting old migartions)

3) Keep synced models & migrations
https://review.openstack.org/#/c/42307/

4) Use in unit tests DB created from models

5) Run unit tests against all backends (not only sqlite)

6) If we implement 3 & 4 we could drop support of sqlite in migration

7) Get rid of soft delete or implement fast and safe purge engine (not archiving).

We have a lot of problems with soft deletion:
1) must have purge engine
2) bad performance
3) complicated logic

It seems that in almost all cases we are able to delete instantly records. So we should deep analyze this situatiin & probably refactor current DB to get rid of soft deletion.


8) Get from DB only what we actually need. Now we are always getting 3 columns "create_at", "updated_at", "deleted_at" (it is half of DB traffic sic.. ) and they are pretty rare used.










(Session proposed by Boris)

Next steps for database improvement:

I'd like to see a general database session in the nova track.

Proposed items to discuss:

* the database CI stuff that Josh Hesketh and I have been working on
* whether a move to alembic makes sense

(Session proposed by Michael Still)


Friday November 8, 2013 2:20pm - 3:00pm
AWE Level 2, Room 204-205

2:20pm

Negative Testing Strategy
Tempest has a lot of negative tests but there is no shared view of how many there should be, or whether they should really
be part of unit tests. There have also been discussions about fuzz testing. Here are a few things that have been discussed and from which a new consensus might emerge:

- We could have a decorator or other kind of syntax that allows a declarative way to define negative tests, but which run in the
same way as existing tests. These would be easier to write and review.

- We could come up with a policy for negative test coverage and move most to unit tests.

- We could have a fuzz testing framework, possibly supported by some kind of type signature for apis to allow checking for
fencepost errors rather than just slinging random arguments

(Session proposed by David Kranz)


Friday November 8, 2013 2:20pm - 3:00pm
AWE Level 2, Room 202

2:20pm

Heat integration and scalability
Etherpad: https://etherpad.openstack.org/p/savanna-icehouse-architecture

This session will include the following subject(s):

Resources orchestration using Heat:

Savanna should use Heat for resources orchestration. There are number of loosely-researched problems in Heat that should be transformed to bug reports / blueprints in both Heat and Savanna projects to track this change.

The overall goal is to replace one-off orchestration with Heat-based one wherever makes sense.

(Session proposed by Clint Byrum)

New architecture and scalability:

Savanna should be horizontally scalable to support a lot of clusters provisioning at the time. On the other side we should solve the problem with provisioning large clusters, for example, by using multiple engines for one cluster.

There are several potential solutions that are grouped from the following components: controller, conductor, engine, agent.

We should take a look at all of the potential components and at production installations of OpenStack to choose the right way to solve scalability problem.

It's strongly connected with Heat integration.

Additional subtopics related to the failure scenarios handling:

* VM provisioning failure - cluster should be usable in case of 1/1000 VMs with only slave processes failed to be able to just add missed VMs instead of cluster reprovisioning;
* timeouts - we should add timeouts for all parts of provisioning process.

(Session proposed by Sergey Lukjanov)


Friday November 8, 2013 2:20pm - 3:00pm
AWE Level 2, Room 201A

3:10pm

common block storage library (brick) take 2
Modified version of Walt's proposal to talk more specifically about the implementation strategy/goals and the challenges involved.

We had some good ideas/goals for a project-shared storage library during the Havana summit. We sort of lost some focus and didn't make the progress here that we could have. This session is intended to hash out some of the ideas around how to implement the scheduling ideas, how to create a sort of "mini" driver via the brick library etc.

Session is a combination of Walter Boring's proposal to discuss library deployment and John Griffith's proposal to dig deeper into implementation strategies.

(Session proposed by Walt)


Friday November 8, 2013 3:10pm - 3:50pm
AWE Level 2, Room 203

3:10pm

Auditing AuthN, AuthZ and Policy Decisions
https://etherpad.openstack.org/p/icehouse-auditing

Discuss designs for auditing Notifications for Low-Level Authentication, Authorization and Policy Decisions

In order to properly audit the access or management of an data or workload governed by a cloud platform, regardless of industry (e.g. Banking, Financial, Healthcare, etc.) or compliance regulations (e.g. Basil, SSAE16, HIPAA, ISO 27000, etc.), all low-level security decisions based upon security identities and policies (including access control groups management and administrator/privileged actions) need precise audit information to be recorded. Ceilometer has recently added support for standardized auditing of external OpenStack APIs which can leveraged for internal auditing of such critical security events. However, these API records need to be correlated to the "control" decisions made by Keystone that the API access decision was based upon.

(Session proposed by Matt Rutkowski)


Friday November 8, 2013 3:10pm - 3:50pm
AWE Level 2, Room 201B

3:10pm

Connectivity Group Extension API
This session is to discuss making the Neutron APIs more application friendly. The Connectivity Group abstraction blueprint is a possible means of making this happen, but we'd like to discuss other ideas around this as well.

(Session proposed by Kyle Mestery)


Friday November 8, 2013 3:10pm - 3:50pm
AWE Level 2, Room 201C

3:10pm

AWS compatibility perspective back into OpenStack
The growth of OpenStack has been largely inclusive of it's own API, making it an excellent choice for private cloud
solutions. However, large cloud vendors such as Amazon AWS remain dominant and continue to excel in the public cloud space.
OpenStack began by providing EC2 API compatibility, and still does, but the growth and innovation around OpenStack API needs to be complemented with continued support for EC2 API, and maintain compatible feature parity with AWS, for it to be really a strong choice for public cloud migration, and adoption.
I think compatibility is an important middle-ground between innovation and existing user migration, and shouldn't be ignored.

A part of the community can contribute to ensuring AWS compatibility in parallel with the ongoing innovation efforts around OpenStack API.
This session proposes the following:
* Present data to show EC2 API compatibility gaps in the current software
* Discuss where third party compatibility testing has lacked, and needs improved coverage, particularly Tempest
* Call for ways the community can collaborate on development efforts for third party compatibility

(Session proposed by Rohit Karajgi)


Friday November 8, 2013 3:10pm - 3:50pm
AWE Level 2, Room 204-205

3:10pm

Enhancing Debuggability in the Gate
As a wrap up session to the QA track I want to discuss ways to increase debuggability in the gate. As our tooling gets more complicated, and parallel testing gets more rigorous, being able to understand the output of gate testing is more and more critical. We need to push towards a world where an issue is debuggable with first fail capture in the logs.

This will be a brain storm and wrap up session to enumerate some priorities on debuggability, changes to tempest, the gate, tools that understand the gate artifacts, and core projects that could get us a better debugging story.

(Session proposed by Sean Dague)


Friday November 8, 2013 3:10pm - 3:50pm
AWE Level 2, Room 202

3:10pm

Further OpenStack integration
Etherpad: https://etherpad.openstack.org/p/savanna-icehouse-integration

This session will include the following subject(s):

Future of CI:

We need to have CI and gating tests.

Currently we're using private lab for running integration tests, it should be eventually moved to the OpenStack Infra.

Subtopics:

* integration tests in Tempest
* integration with DevStack
* adding Savanna to Gating

(Session proposed by Alexander Ignatov)

Metering/monitoring using Ceilometer:

There are several needed directions for integration with Ceilometer:

* monitoring of internal Savanna state including number of provisioned clusters, amount of used CPUs, RAM, etc.
* monitoring of internal provisioned clusters state including number of currently running jobs, free/busy mappers and reducers.

(Session proposed by Sergey Lukjanov)

Baremetal using Ironic:

Savanna should use Ironic to provision bare metal and hybrid clusters.

(Session proposed by Sergey Lukjanov)


Friday November 8, 2013 3:10pm - 3:50pm
AWE Level 2, Room 201A

3:50pm

Break
Friday November 8, 2013 3:50pm - 4:10pm
OpenStack Quad

4:10pm

Volume Import
IBM have some internal implementation of Volume Import that we would like to push back to the community. However, there are some interesting issues around volume import that I think warrant discussion:

1. Some Cinder drivers rely on the name of the volume matching the OpenStack-internal 'name'. This means that a driver either has to rename the volume on import, or support a decoupling between the openstack-internal name and the backend volume name. We have prototyped the Storwize driver using the admin_metadata added for read-only volumes to do this decoupling.

2. Volume Types are used to guide the creation of the backend volumes. If a volume import operation were allowed to specify a volume type, should the drivers be checking that the backend volume is in some way "compliant" with the volume type? Any such check would likely be unreliable, since there may be more features on the backend storage provider than the driver supports, and the driver can't check that it doesn't know about.

3. Our implemented also added an API extension that could retrieve a list of backend volumes that were eligible for import. Is this considered a core feature, or something that could be optional?



(Session proposed by Geraint North)


Friday November 8, 2013 4:10pm - 4:50pm
AWE Level 2, Room 203

4:10pm

Network Mini Sessions
This session will include the following subject(s):

ML2: Multiple Backend Support:

ML2 plugin potentially supports multiple backend technologies. In Havana, we can use a single backend at the same time.

Considering usecases in cloud data centers or NFV, there are cases where one VM want to connect multiple networks with different networok backend. For example, one interface is connected to Linux Bridge with VLAN for a frontend network and another interface is connected to OVS controlled by SDN controllers for internal network. (We already see a similar case in br-int and br-ex on l3-agent.)

To achieve it, the following topics needs to be considered:
- How to specify backend technologies when creating a network (through extension)
- Machanism driver support
- Nova VIF driver determines a bridge connected to a VIF based on information from Neutron (by extending the port binding extension)

It is somthing different from provider:network_type. network_type specified which protocol (VLAN, GRE, VXLAN, ...) is used for a tenant network and it can work on a single backend technology such as Linux Bridge or OVS.

It may not be specific to ML2 topic but I think ML2 is a good start point of this topic.

(Session proposed by Akihiro Motoki)

Improving the Provider API:

So far in Neutron, there has been more focus on the tenant-facing API than the provider's. For Icehouse, we believe that Neutron API should evolve to provide richer capabilities for the providers. In this session, we would like to discuss the following topics:

Provider Router:

Neutron should let the provider and tenants own their own routers, and they should be able to link the routers together. This enables the model of tenants linking their routers to the provider-owned uplink router. This gives the providers more control over the internet/inter-tenant traffic that passes through its edge router.



(Session proposed by Ryu Ishimoto)


Friday November 8, 2013 4:10pm - 4:50pm
AWE Level 2, Room 201C

4:10pm

Hyper-V: Icehouse features
Discussing the features that we want to add for Hyper-V support in Icehouse

(Session proposed by Alessandro Pilotti)


Friday November 8, 2013 4:10pm - 4:50pm
AWE Level 2, Room 201B

4:10pm

Icehouse release schedule & coordination
This session will include the following subject(s):

Icehouse release schedule & coordination:

In this session we'll discuss and decide the deadlines and milestones for the Icehouse coordinated release cycle. We'll also discuss potential changes in the process, the format of the weekly release status meeting, and the improvements needed to the toolset supporting the release management tasks.

(Session proposed by Thierry Carrez)

Considering translation in release cycle:

In Havana release, I18n team worked together with Horizon team to complete 12 languages translation (1700+ strings) and run the translation verification test ( reported 15+ bugs related with I18n) within 1 month from string frozen date to RC2. In Icehouse release, we are going to cover more components, that means, more strings need to be translated. 1 month may be not enough.

We need to find a way to give translators enough time for translation and verification test. We can discuss this in this session.

(Session proposed by Ying Chun Guo)


Friday November 8, 2013 4:10pm - 4:50pm
AWE Level 2, Room 204-205

4:10pm

Savanna in Icehouse
Etherpad: https://etherpad.openstack.org/p/savanna-icehouse-roadmap

This session will include the following subject(s):

Savanna roadmap for Icehouse:

This session should finalize discussions about Savanna at design summit to define scope and roadmap for further Icehouse release cycle.

(Session proposed by Sergey Lukjanov)

EDP in Icehouse:

We should discuss further roadmap for Elastic Data Processing.

* Overall direction of EDP.
* Short-term and long-term goals.


(Session proposed by Sergey Lukjanov)


Friday November 8, 2013 4:10pm - 4:50pm
AWE Level 2, Room 201A

5:00pm

Richer API rate limits in cinder
Currently, the only API rate limits in cinder are via the paste pipeline. This is limiting since you don't have (easy) access to the details of the call, nor the existing state of the system.

We propose adding a new pluging that gets called at the start of any API call that can implement richer ratelimits. An example of a rich rate limit is you can only create 10Tb of volumes a day. This is different to the existing quota mechanism, and is required to remove some DoS attacks on certain backend concepts.

(Session proposed by Duncan Thomas)


Friday November 8, 2013 5:00pm - 5:40pm
AWE Level 2, Room 203

5:00pm

Neutron Stability
In this session we will examine how to address the race conditions that caused problems during the Havana development cycle.

(Session proposed by Mark McClain)


Friday November 8, 2013 5:00pm - 5:40pm
AWE Level 2, Room 201C

5:00pm

The future of Design Summits
"Design Summits" are a key moment in OpenStack development cycles where our development community gathers to brainstorm the next steps for our project. It always happened more or less at the same time as the traditional "Conference", without causing too much conflict, with the key technical contributors mostly ignoring the conference to concentrate on the 4-day design summit.

However, with the explosive growth of OpenStack and the success of the conference, it is a problem to prevent our best technical resources from presenting and attending the conference. We need to discuss ways to organize those events in the future which would enable more participation from our technical contributors.

We'll also discuss the design summit format, how we select sessions and schedule them, as well as needed evolutions on the ODSREG application (summit.openstack.org).

(Session proposed by Thierry Carrez)


Friday November 8, 2013 5:00pm - 5:40pm
AWE Level 2, Room 204-205