Loading…

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

Design Summit [clear filter]
Monday, April 15
 

9:50am

OpenStack-on-OpenStack Overview

In this session, I will talk about some of the problems we face in deploying openstack by using openstack. I'll point at areas where the bare metal driver needs better integration with other services (eg. Quantum and Cinder), how we really need an inventory database (I'm looking at you, HealthNMon), how the Nova scheduler needs to be aware of hardware, and how Heat is taking over the world. I might even propose that it's possible to bootstrap yourself right out of your own boots!


(Session proposed by Devananda van der Veen)


Monday April 15, 2013 9:50am - 10:30am
B113

11:00am

python-novaclient
This session will include the following subject(s):

python-novaclient:

python-novaclient needs fixing, lets fix it.

Some current issues with the client:

* Poor testing (nova commands are commonly broken against latest API)
* No testing across multiple releases (should work against Essex, Folsom, Grizzely etc)
* Doesn't covers many nova-apis (including extensions)
* Should be able to list commands that current endpoint supports (by using list-extensions)


(Session proposed by Joe Gordon)

novaclient experience for end users:

There are some aspects of the novaclient experience that can be improved for users. This is similar to what's being proposed at http://summit.openstack.org/cfp/details/74 but with a focus on users.

A few issues:
* --help is overwhelming to a new user, and lists capabilities that may not be available from a particular provider.
* admin functions are listed even for a non admin user.
* Should it be possible to setup credentials in a config file?

(Session proposed by Andrew Laski)


Monday April 15, 2013 11:00am - 11:40am
B113

11:50am

Versioned internal objects
In order to support rolling upgrades, we need to get away from having our internal objects directly mirror the DB schema.

Up for discussion is versioned objects, automatic serial and deserialization on RPC, etc.

(Session proposed by Dan Smith)


Monday April 15, 2013 11:50am - 12:30pm
B113

1:50pm

Database Status Redux
A lot of work was done on Nova's database back-end during Grizzly, including but not limited to:

- no direct db access from nova-compute
- cleaning up the db API
- better use of sessions
- adding real unique keys
- archiving deleted rows
- better support for postgres

Let's all get together and discuss what went well, what we didn't finish, and what we want to do next!

(Session proposed by Devananda van der Veen)


Monday April 15, 2013 1:50pm - 2:30pm
B113

2:40pm

Zero downtime service upgrades
Discuss strategies for working towards zero-downtime maintenance.

1) Stopping services gracefully, completing existing requests before quitting.
2) Make computes 'kill' friendly by enabling long running processes to resume after a restart. (e.g. resize)

(Session proposed by Brian Elliott)


Monday April 15, 2013 2:40pm - 3:20pm
B113

3:40pm

The (continuing) path to live upgrade
Still more work needs to be done to provide a true path to rolling upgrade, such as RPC client N-1 version support.

(Session proposed by Dan Smith)


Monday April 15, 2013 3:40pm - 4:20pm
B113

4:30pm

Nova v3 API
The Nova v2 API has several problems with it that can not be fixed by modifying the v2 API as it would cause compatibility problems with existing clients. The purpose of this summit session is to discuss the problems with the v2 API and how we will fix them with the v3 API. Issues include but are not restricted to:

* Clarification of what is to be core and non-core
* Decide on objective criteria for deciding how to classify this
* Promotion/Demotion of functionality into or out of core
* Consistency of return codes
* Fix extensions which don't follow REST principles
* Fix XML/JSON inconsistencies
* How to handle versioning for extensions (no more extending
extensions!)
* Copy v2 tree and rework in place?
* Timeline for work (h1/h2/h3 targets)
* Make sure we have enough time to bring up tests as well
as convert extensions developed during the Havana cycle so v2 only has to exist for the I cycle before being deprecated.
* Develop "good practice" guide for writing extensions


(Session proposed by Christopher Yeoh)


Monday April 15, 2013 4:30pm - 5:10pm
B113

5:20pm

Nova API Extension framework
The development of the Nova v3 API will give us the opportunity to rework the extension framework. The current framework suffers from:

* extensions specific code required to exist in core code for specific extensions to work
* compromises such as non pep8 class names because of the extension framework

The purpose of the summit is to discuss proposals of how the newextension framework will work and hopefully gain from previous experiences on extension points used in other places such as scheduler hints/keypairs etc.

(Session proposed by Christopher Yeoh)


Monday April 15, 2013 5:20pm - 6:00pm
B113
 
Tuesday, April 16
 

11:00am

Nova scheduler features
This is a session on features people would like to add to the current scheduler in Nova. It's packed with ideas. We will do our best to discuss as much as we can in the time available. Topics that need more time can be scheduled for the unconference track later in the week.

This session will include the following subject(s):

Extend the Nova Scheduler view of mutable resource:

Currently the Nova host_manager keeps track of the Disk, Memory and vCPU resources of each host which are then available for use in scheduler filters. These are also reflected in the flavour definitions.

I’d like to discuss extending this to cover additional resource types such as:

Compute Units : An measure of CPU capacity, that is independent of the physical CPU performance of a server models and independent of the vCPU configuration of a VM . Each server would report its total Compute Unit capacity.
The flavor "vcpu_weight" would seem to meet the requirement in terms of definition, but it seems to be something of a hidden value (the instance_types create() method doesn;t support it for example) and its not currently tracked as a mutable resource in the host_manager.


Network Bandwidth: An measure of network bandwidth that is independent of the network capacity of a server. Each server would report its total network bandwidth capacity. The current rxtx_factor is the flavours looks like it could be logically used to represent this, but the current usage seems to be in conflict with being an arbitary measure of bandwidth sinceit represents a % the rxtx_base value of a network. A Nova system could include hosts with 1Gb, 10Gb, multiple 10Gb network configurations connected to the same logical network.


These are two examples of additional flavour and host attributes, there will probably be others either now or in the future. Flavors already provide an extra_spec that could in theory be used to define these, but there is no way to expose the corresponding host capacity to scheduler filters. The host manager does support a “capabilities” feature, but this is more of a binary value that a consumable resource.

Possible options are:
- Add the existing vcpu_weight and rxtx_factor as specific mutable resources in the host manager. May be a conflict here between current usage in xen and the more general definitions of resources.

- Add additional flavour & host manager resources, to avoid overload / conflict with current usage of vcpu_weight and rxtx_factor.

- Provide a generic mechanism for the host manager to support additional mutable objects that correspond to and can be consumed by flavour extra_spec values.

In addition to making this data available to the scheduler, it also needs to be consumable by a resource management layer that may be to some extent independent of the virtualisation library. For example it is an established design pattern to implement resource management via an agent running outside of Nova itself – for example an agent which is triggered via a libvirt hook when a VM is created. Currently such an approach only has access to the flavour aspects which are part of the VM definition. This proposal would (for libvirt) create an additional XML file per VM that contains the full flavour definition.


(Session proposed by Phil Day)

List supported Scheduler Hints via API:

https://etherpad.openstack.org/HavanaNovaSchedulerHintsAPI

The Nova API for instance creation supports a scheduler_hints mechanism whereby the user can pass additional placement related information into the Nova scheduler.

The implementation of scheduler_hints lies (mostly) in the various scheduler filters, and the set of hints which are supported on any system therefore depends on the filters that have been configured (this could include non-standard filters). It is not currently possible for a user of the system to determine which hints are available. Hints that are not supported will be silently ignored by the scheduler

We propose to add an API extension to make the list of supported hints available to users.

(Session proposed by Phil Day)

Rack aware scheduling in Nova:

https://etherpad.openstack.org/HavanaNovaRackAwareScheduling

A common requirement for analytical applications (amongst others) is to want to place related workloads on the same rack so as to take advantage of the increased network bandwidth. In order to support this we need:

This is similar to the existing affinity scheduler filter, but requires additional per server attributes to be exposed. We would like to discuss whether this can be achieved by extending the existing capabilities mechanism.

(Session proposed by Phil Day)

Add "whole host" allocation capability to Nova:

https://etherpad.openstack.org/HavanaNovaWholeHostAllocation

Allow a tenant to allocate all of the capacity of a host for their exclusive use. The host remains 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.

We will present a proposal that could achieve this by building on existing host aggregate and scheduler filters.

Extending this further in the future could form the basis of hosted private clouds - i.e. schematics of having a private could without the operational overhead.

The required features are explored by stepping through the main use cases in the Etherpad.

(Session proposed by Phil Day)

Make scheduler host state extensible:

Overview:

The nova scheduler is periodically sent updates from each of the compute managers about the latest host capabilities / stats. This includes available ram, the amount of IOPS, the types of supported cpus, number of instances running, etc. Scheduler filters can then be defined, and guided using scheduler hints, to use this information to improve instance scheduling.

It would be useful if the information could be generalized so that services other than compute could also update the scheduler's host information.

Benefits:

* 3rd party extensions can feed information into the scheduler that their SchedulerFilters can interpret and make better scheduling decisions.

* This could be a good step in moving more scheduler code into oslo-incubator. The common scheduler code can accept updates for any source (e.g. cinder manager in cinder's case or compute manager in nova's case).

* If the scheduler does become a full independent service then this type of functionality will be required (i.e. the scheduler will need to make a decision based on information from both Cinder and Nova).

Related Summit Talks

* http://summit.openstack.org/cfp/details/121
Features like this could be implemented as small daemons on the hosts that can cast a message to the scheduler about the host rack ID.

* http://summit.openstack.org/cfp/details/120
Since we are opening up more customization to the type of data available to the scheduler, and the potential filters installed, this would be a good feature.

* http://summit.openstack.org/cfp/details/36
Updates the information that is sent to the Scheduler.


(Session proposed by David Scannell)

Coexistence of different schedulers:

Today in Nova only one scheduling algorithm can be active at any point in time. For environments that comprise multiple kinds of hardware (potentially optimized for different classed of workloads), it would be desirable to introduce flexibility in choosing different scheduler algorithms for different resource pools (aggregates). This can be done ei

Tuesday April 16, 2013 11:00am - 11:40am
B113

11:50am

Scheduling across nova/cinder/networking
This session will include the following subject(s):

Scheduling across nova/cinder/networking:

The goal is to be able to schedule resources across nova/cinder/networking efficiently. A simple example could be the 'boot from volume' scenario, when it would be highly desirable to make sure that the instance and the volume reside "close enough", as reflected by the underlying network topology (provided by OpenStack Networking, probably).

(Session proposed by Alex Glikson)

Unified resource placement for OpenStack:

Background:

The current Nova scheduler does not take into account the connectivity request among a bunch of VMs (bundled VMs) neither the physical topology. For example, there is no API that allows users to specify that all VMs should be placed in compute nodes that are not more than 2 hops away with at least 50Mbps residual bandwidth available on the path connecting these two VMs. Even though with current scheduler APIs, users could specify the exact hosts to place the VMs to achieve certain network affinity. But this requires very detailed physical topology information which might not be available to tenants. Another example is that the block storage manager (nova-volume or Cinder) currently selects nodes randomly. This could cause unnecessary load on network as well as latency to the application.

How to address these problem:

Ideally, a higher level manager should be developed to oversee and coordinate the compute, storage, and network manager for a more efficient resource usage. Another important benefit is that tenants now can specify their requests of compute, storage, and network in a bundled manner. They should not really care about the fine grained details on how to connect their application servers and worry about competing the network and storage resources with other tenants. There have been a lot of interests in this area (See for example https://etherpad.openstack.org/the-future-of-orch).

Goal of this session:
This session should serve as a good venue to discuss the problem definition, the related blue prints, potential solutions, pitfalls we want to avoid and the timeline to implement a sound placement module for OpenStack. We should also discuss whether we should separate the workflow management from the resource (node) selection for better modularity.

(Session proposed by Senhua Huang)


Tuesday April 16, 2013 11:50am - 12:30pm
B113

1:50pm

Group scheduling
This session will include the following subject(s):

Placement groups in Nova:

EC2 recently introduced Placement Group APIs to ensure proximity of HPC instances within a group (http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using_cluster_computing.html).
The proposal is to introduce similar APIs in Nova, potentially supporting also additional placement policies/strategies, such as anti-affinity for availability purposes. As a next step, the goal is to refine the notion of proximity/anti-affinity to be able to reflect different levels of "proximity"/"isolation"/etc (e.g., "different racks"). As a result, it will be possible to reflect membership of instances in groups in a more efficient way (compared to using metadata today), and to drive placement decisions by the scheduler in a more flexible and intelligent way.

(Session proposed by Alex Glikson)

VM Ensembles (Group Scheduling) - API:

The session will propose and discuss the notion of group scheduling. An API will be proposed to enable the user to perform the scheduling of a group. The group scheduling will enable the tenant to benefit from filters that provide anti affinity and network proximity to provide elevated service levels in terms of (high) availability and performance to applications that run in the cloud.


(Session proposed by Gary Kotton)


Speakers
avatar for Alex Glikson

Alex Glikson

Manager, Cloud Operating System Technologies, IBM Research
Mr Alex Glikson is leading a research group at IBM Haifa Research Lab working on research and development of innovative cloud infrastructure management technologies - focusing on OpenStack (http://www.research.ibm.com/haifa/dept/stt/cloud_sys.shtml). In this role Alex closely col... Read More →
avatar for Gary Kotton

Gary Kotton

Staff Engineer at VMware, VMware
Gary is a core Neutron developer working at VMware who also spends a lot of his time these days writing + reviewing code for Nova. Prior to working at VMware Gary worked at Red Hat, Radware and at Algorithmic Research. Gary holds a Bs.C in Mathematics and Computer Science from the... Read More →


Tuesday April 16, 2013 1:50pm - 2:30pm
B113

2:40pm

Nova Compute Cells Status
This session will include the following subject(s):

Nova Compute Cells Status:

In this session, I plan to discuss the current status of cells in trunk. Now that a basic working version has landed, I think it would be useful to refresh people on what functionality trunk provides. There are a number of features that cells does not support. I plan to discuss those and other TODO items.


(Session proposed by Chris Behrens)

Cell support in Ceilometer:

We need to review the changes we may need to make in Ceilometer to support Nova Cells.


(Session proposed by Nick Barcet)


Tuesday April 16, 2013 2:40pm - 3:20pm
B113

3:40pm

The future of state management in nova
Likely this could be joined with http://summit.openstack.org/cfp/details/72 but I would like to focus more on the prototype that NTT and I have been working on and show the code and the architecture and discuss where to go from here to getting this code fully used throughout nova.

Talking points:
* Current architecture and thoughts on the current and future architecture of state management and how the future provides more benefits than the current status-quo.
* What has been prototyped and how far it has gotten.
* State transitions & rollbacks.
* Some fundamental changes that need to be applied...
* How this relates to conductor effort? Does it?
* What name to call this effort (people seem to get confused with anything call orchestration)?
* Where this can go from here and other feedback...
* State management in other components.
* How to get from here to there.
* How to help out!

Hopefully either code can be shown or even a demo of the prototyped code, depending on time allocated and how much time is free to show this. Mainly I would like to ensure the design that was prototyped is discussed, its benefits shown and get everyone on-board that this is the desired future way of doing things and get people involved in fixing up nova to make it be all it can be.

(Session proposed by Joshua Harlow)


Tuesday April 16, 2013 3:40pm - 4:20pm
B113

4:30pm

Nova Scheduler as a Ceilometer client?
This should be the continuation of a discussion with Vishvananda about how nova sheduler could use ceilometer to take its measurements from.

(Session proposed by Nick Barcet)


Tuesday April 16, 2013 4:30pm - 5:10pm
B113

5:20pm

Unified Event Notifications
We have:
1. The AMQP notifications,
2. The DB InstanceFault table,
3. Exception handling decorators,
4. The conductor mechanisms you've highlighted,
5. and, to a lesser extent, logging

Can we unify some or all of these efforts to clean up the code?

(Session proposed by Sandy Walsh)


Tuesday April 16, 2013 5:20pm - 6:00pm
B113
 
Wednesday, April 17
 

11:00am

Richer and more flexible APIs for block devices
A number of blueprints relate to block devices configuration and controling the cinder volumes. They not only propose enhancements but also raise questions that suggest a deep rework of the internal API between compute manager and compute drivers.

This session would be about

* what should be reworked in the internal API between compute manager and compute drivers
* explaining how the blueprints all fit together
* defining what can be achieved for Havana
* what should be next although it's unrealistic for Havana

The API currently implements an abstraction (inherited from EC2) that does not map to the abstraction of the virtualisation layer. The external API should be modified first and then it will be easier to rework the internals. For backward compatibility, the old API would be preserved.

The virtualization abstraction follows the EC2 api exactly ( a hash from the EC2 abstraction is passed to the virtualization driver which requires guessing from the driver ). The virtualization abstraction needs to be modified to be able to take advantage of a better API.

Josh Durgin and Nikola Đipanov are implementing the blueprints.


(Session proposed by Loic Dachary)


Wednesday April 17, 2013 11:00am - 11:40am
B113

11:50am

Nova Updates for Disk Encryption
There are two blueprints for doing disk encryption with Nova: 1)
Encryption of Attached Cinder Volumes (has a working prototype) and 2)
Encryption of Local Ephemeral Disks. This session presents the
architecture of our prototype implementation to solicit feedback from
the community and to discuss open questions regarding the current
implementation prior to its submission for Havana. Consensus from the
community is also desired regarding how to extend the existing prototype to support encrypted ephemeral storage.

(Session proposed by Laura Glendenning)


Wednesday April 17, 2013 11:50am - 12:30pm
B113

1:50pm

Roadmap for Ceph integration with OpenStack
The content of this session is collaboratively edited at https://etherpad.openstack.org/roadmap-for-ceph-integration-with-openstack

Although Ceph is already integrated with OpenStack for object and block storage, it can be improved for an easier and more flexible configuration, authentication, metering, monitoring, security, placement, encryption etc.
For instance, volume encryption ( https://blueprints.launchpad.net/nova/+spec/encrypt-cinder-volumes ) and the associated blueprint ( https://wiki.openstack.org/wiki/VolumeEncryption ) should probably be aligned with the experimental dmcrpyt support for Ceph ( http://marc.info/?l=ceph-devel&m=136089346527439&w=4 )
The OpenStack components are either have an intimate knowledge of Ceph ( nova, cinder, ... ) or are loosely coupled with it ( ceilometer, ... ).
Tentative agenda:
* The state of Ceph integration in
* Nova
* Cinder
* Ceilometer
* ...
* High level overview of the existing blueprints related to Ceph.
* Overview of the current state of the Ceph integration with OpenStack
* Presentation of the blueprints that are related to Ceph
* What should be in Havana ?
* What should be in I* ?
* Who can commit to what ?
Related blueprints
* https://blueprints.launchpad.net/nova/+spec/encrypt-cinder-volumes
* https://blueprints.launchpad.net/nova/+spec/flexible-block-device-config
* https://blueprints.launchpad.net/nova/+spec/block-mapping-model
* https://blueprints.launchpad.net/nova/+spec/improve-block-device-handling
* https://blueprints.launchpad.net/nova/+spec/improve-boot-from-volume
* RBD backups to secondary clusters within Openstack
** Geo-replication with RADOS GW http://marc.info/?l=ceph-devel&m=135939566407623&w=4
** Geographic DR for RGW http://marc.info/?l=ceph-devel&m=136191479931880&w=4


(Session proposed by Loic Dachary)


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

2:40pm

Improve Host Maintenance and Migrate APIs
This session will include the following subject(s):

Improve Host Maintenance and Migrate APIs:

If there is a pending server failure (i.e. several disks have failed in RAID array, etc) then you want to evacuate the host to perform the maintenance.

If you are patching your hypervisor, you might want to suspend all the VMs onto the local disk, upgrade, then resume those VMs.

To do this manually, it would be good to list all VMs on a host. Ideally we would have some orchestration to help do the full operation.

A related issue is that the Migration and live-migration grew up independently. Lets come up with a plan for an API that unify the migrate and live-migrate behind a single (extended) migrate API.

There is an Etherpad:
https://etherpad.openstack.org/HavanaUnifyMigrateAndLiveMigrate

(Session proposed by John Garbutt)

Streamlining mobility-related scenarios in Nova:

Today in Nova there are multiple scenarios involving VM instance mobility, each following different design approach (target selection, resource tracking, ability to verify success and/or undo, etc). As a first step, these operations must be refactored, to follow a single design approach, and to provide consistent and robust capabilities. Then, higher-level scenarios such as host maintenance, ongoing optimization, VM HA can be properly implemented, leveraging the improved individual mobility operations (also involving certain orchestration logic on top). The goal of this session would be to discuss and agree on these design principles, and outline a roadmap to make the necessary changes during Havana release cycle.

(Session proposed by Alex Glikson)


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

3:40pm

Mothball a server
This session will include the following subject(s):

Mothball a server:

Today when you stop a server, it remains on the hypervisor host.

Many users, with less cloud like workloads, want the ability to stop servers when they don't need them, but to retain IP addresses and current disk state (including ephemeral), so they can start it up at some time in the future.

From an operator perspective, this should take up minimal resources. Preferably, only storage space.

Lets look at how best to implement this within Havana. See Etherpad for discussions:
https://etherpad.openstack.org/HavanaMothballServer


(Session proposed by John Garbutt)

Make Nova Stop/ Start operations release physical :

The current Nova stop/start schematics leave an instance associated to the same host, so the scheduler has to keep the resources on that host allocated so that the instance can be re-started. From a service provided perspective this means that it’s hard to offer any financial advantage to stopped instances since they are in effect still consuming the same amount of logical resources.

It’s already noted in the code that the current stop/start should really be renamed power-off/power-on since that is what they actually do.

We would like to be able to exploit boot from volume so that users can “stop” an instance preserving all of its network settings, metadata, instance_id, etc but remove the consumption of any physical resources. On start the instance would be re-scheduled to a new host.

The basic operations would be:
Stop: Power down the instance, and remove any local storage associated with the instance

Start: Reschedule the instance to a new host, and start the instance on that host as if it had been newly created (from a local disk perspective)

Restart: A combined Stop/Start command

Stop should always complete, even if the host the instance is currently running on is down.

Any data in volumes (including boot volumes)would be preserved. Any data in ephemeral discs would be lost.

It would seem logical to take this opportunity to rename the current stop/start to power-off/power-on and re-use the stop/start verbs for this operation.

(Session proposed by Phil Day)


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

4:30pm

Handling long running periodic tasks
nova-periodic caused a lot of discussion on the mailing list. I now have a proposed implementation, and I'd like to discuss with others if we like the proposed approach, or have a better plan.

(Session proposed by Michael Still)


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

5:20pm

Nova API validation framework
Overview:
Nova has many RESTful APIs, and not all API parameters are completely validated.
To implement comprehensive validations, I'd like to propose Nova API validation framework.
The benefits of this framework will be the followings:
* Validate every API parameters.
* Unify an error message format of the response, if the same cause.
ex) ".. is too short.", ".. is too long.", ".. is not integer."
* Clarify the API parameter definitions.
* Clean up codes, because of merging error handling methods.

Talking points:
I created a prototype for API validation framework, and found some points which need discussions.
I'd like to talk/discuss about the following in this session:
* Overview of API validation framework
* Plans for Havana release
** Current development status
** What are TODOs for Havana?
** Migration plans (How to apply the framework to all APIs smoothly)
Need Nova community agreement because of many implementations and reviews.
Need useful framework to implement each API validation step by step.
Need some implementation rules to achieve all APIs by Havana release.
* Next features of the framework
* And more

Related Summit Talk:
There was a similar session in Grizzly Design Summit, and the session contained good discussions for API validation:
* Refactoring API Input Validation:
https://etherpad.openstack.org/grizzly-nova-input-validation
In the session proposed by me, I'd like to discuss how to achieve implementations of all APIs based on some prototype.


(Session proposed by Ken'ichi Ohmichi)


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

9:00am

OpenStack Networking and Nova - Part 2
OpenStack Networking and Nova, part 2. See part 1 here, in the Networking track:

http://summit.openstack.org/cfp/Details/161

Part 2 is where we will get back together near the end of the design summit to recap our plans for OpenStack Networking+Nova and identify specific work that needs to get done by both projects to accomplish our goals.

(Session proposed by Russell Bryant)


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

9:50am

VMware compute driver roadmap session
This session will include the following subject(s):

VMware compute driver roadmap session:

Brainstorming session to help coordinate among everyone who is planning on contributing the to VMware compute driver during the havana session.

Goal is to avoid any more duplicate work, identify key gaps, and to prioritize what new features will be most valuable.


(Session proposed by dan wendlandt)

Nova Proxy compute driver for vCenter:

This session is to cover the following blue prints.

1. Multiple VMware vCenter Clusters managed using single compute service
2. VMware Resource Pools as compute node
3. VMware vCenter compute driver and scheduler enhancements to publish and consume cloud capacity of clusters and resource pools
4. VMware vCenter templates available as glance images
5. Nova changes for VMware vCenter templates

(Session proposed by Srinivasa Acharya)


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

11:00am

libvirt driver in Havana
This session is to discuss improvements we would like to make to the libvirt driver in the Havana cycle. Feel free to show up with additional ideas you would like to discuss.

This session will include the following subject(s):

libvirt console logging:

libvirt console logging is still broken, and it has been for ages. We're re-written it at least three times. Let's come up with a plan for fixing it that will actually work this time.


(Session proposed by Michael Still)

LXC Block Devices:

Use the libvirt-lxc functionality to mount block devices rather than have NOVA do it for us. Newer versions of libvirt allow block devices inside the container in order for it to be accessible so we should change the way NOVA mounts the images before we start the container.


(Session proposed by Chuck Short)


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

11:50am

Enhanced Platform Awareness – For PCIe Devices
This session will include the following subject(s):

Enhanced Platform Awareness – For PCIe Devices:

Background:
There is a growing movement in the telecommunications industry to transform the network. This transformation includes the distinct, but mutually beneficial disciplines of Software Defined Networking and Network Functions Virtualization. One of the challenges of virtualizing appliances in general, and virtualizing network functions in particular, is to deliver near native (i.e. non-virtualized) performance. Many virtual appliances have intense I/O requirements, many also could benefit from access to high performance accelerators for workloads such as cryptography, and others would like direct access to GPUs.

There is also a growing demand for the cloud OS to have greater awareness of the capabilities of the platforms it controls. The Enhanced Platform Awareness (EPA) related updates proposed to OpenStack aim to enable better informed decision making related to VM placement and help drive tangible improvements for cloud tenants. This EPA proposal focuses on how to leverage PCIe devices in cloud infrastructure, and looks in particular at Single Root IO Virtualization (SR-IOV) as one technology that can be used to dramatically improve the performance in the virtual machine.

Proposal:
During this design session, the proposal is that the following topics will be covered:
• Discuss the use cases for OpenStack managed PCI devices and allocation of Virtual Functions with SR-IOV.
• Discuss the design proposal for enabling an SR-IOV solution. This shall include:
o Nova enhancements to include a level of awareness of the PCI devices that are included in the platforms.
o Scheduler/filter extensions to find platforms with a specified PCI device.
o Hypervisor driver (libvirt in this first instance) additions to provision a VM with an SR-IOV PCI device.
• The majority of the focus will be on accelerator type of devices. However, some concept proposals relating to how this could be extended to the allocation of SR-IOV Virtual Functions for NIC devices will be discussed.
• Agree on a direction for a solution.

This design session and the related blueprint builds upon ideas already proposed in forum discussions and the following blueprints:
nova/xenapi-gpu-passthrough
nova/pci-passthrough
nova/pci-passthrough-and-sr-iov


(Session proposed by Adrian Hoban)

libvirt pcipassthru support:

Add libvirt pcipassthru support for nova.

(Session proposed by Chuck Short)


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

1:30pm

XenAPI Roadmap for Havana
Get all developers working on XenAPI related features in the same room. Share ideas and set priorities for Havana.

Ideas are forming on etherpad:
https://etherpad.openstack.org/HavanaXenAPIRoadmap

(Session proposed by John Garbutt)


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

2:20pm

Baremetal Hypervisor Driver - Next Steps
Nova now includes a functional baremetal driver with support for PXE-based imaging and IPMI-based power control. This has generated a lot of interest from datacenter operations' teams and many questioning when it will support: hardware discovery, configuration, and BIOS / firmware management; other types of hardware, such as ARM processors and PDU power control; and the possibility to interface with proprietary control modules (iLO / DRAC / etc).

I believe the baremetal driver should provide a means for hardware vendors to easily extend it and take advantage of their control modules, while also providing generic tooling to accomplish these common operational tasks. As the complexity of the baremetal driver grows, its database needs will also grow, and the possible interactions between this "hardware inventory database" and quantum, cinder, healthnmon, etc, will need to be understood.

(Session proposed by Devananda van der Veen)


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

3:20pm

Multi-hypervisor-clouds
Operators deploying openstack using openstack currently have to run two clouds: one undercloud using bare metal, and one overcloud that is fully virtualised and runs on the underlying cloud. This is a bit of a pain, as things like quantum really are common - and operator workloads that could be virtualised cannot be.

So - lets figure out whats needed to run a single cloud combining baremetal and virtual hypervisors. (Obvious issues are different default networks depending on hypervisor, and scheduling workloads onto virtual/real machines).

(Session proposed by Robert Collins)


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

4:10pm

Hyper-V Havana roadmap
Discuss Havana features for Hyper-V OpenStack integration.

(Session proposed by Alessandro Pilotti)


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

5:00pm

RHEV-M/oVirt Clusters as compute resources
This session proposes customers who have RHEV-M/oVirt Management solutions in their data centers to make use of RHEV-M/oVirt Cluster as an elastic compute pool in OpenStack.

The proposal is to have a nova compute proxy connects to a RHEV-M/oVirt through oVirt Rest APIs and expose configured clusters as a compute hosts.

• To allow a single RHEV-M/oVirt driver to model multiple Clusters in RHEV-M/oVirt as multiple nova-compute nodes.
• To allow the RHEV-M/oVirt driver to be configured to represent a set of clusters as compute nodes.
• To dynamically create / update / delete nova-compute nodes based on changes in RHEV-M/oVirt Clusters.

With this driver, there is no change expected in the scheduler. The RHEV-M templates which are available as glance images can be used to create instances.

(Session proposed by Srinivasa Acharya)


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