OpenStack Compute PTLMichael Still

OpenStack Compute in Juno

What is OpenStack Compute?

Themes for Icehouse?● Better CI will result in a more reliable experience for operators● Work towards live upgrade● Cleanups of our APIs to make them easier to use

Where did we end up in Icehouse?● 65 blueprints implemented, 652 bugs fixed● 293 developers submitted at least one patch● 42 developers had at least ten patches

Where did we end up in Icehouse?● Limited live upgrades● Upgrade controllers and set:

[upgrade_levels]compute=icehouse-compat

● Then upgrade compute nodes slowly● Unset:

[upgrade_levels]compute=icehouse-compat

Where did we end up in Icehouse?● API● There was a lot of work on a v3 API in Icehouse, but API

users should remember this work is still considered experimental

● You can now permanently remove decommissioned compute nodes

● XML support was deprecated in Icehouse, and will be removed soon. This should be transparent to most users.

Where did we end up in Icehouse?● Other● File injection is now disabled by default, use metadata

server or config drive instead● Hypervisor driver specific flags have been moved into

groups related to the relevant driver to make the flag namespace less confusing

● There was an experimental Docker driver which has moved from nova to stackforge in this release

● The PowerVM driver has been removed at IBM’s request

Themes for Juno?● Continued improvements to our CI systems● Work towards live upgrade● The experimental v3 API becoming a series of microversions on

top of our current v2 API

Where are we going in Juno?

● New specifications process

● A formal document which defines what is being implemented

● Which is reviewed separately from the code

● Operators encouraged to participate

● We still have a large number of specifications under review

● A summary of currently approved specifications:

● https://wiki.openstack.org/wiki/Nova/Juno-Specs

Where are we going in Juno?● Further work on live upgrades● We want to be able to support live upgrades, but in order to

do this we need to move to an internal object model with versioned objects. This is a lot of work, but is underway.

Where are we going in Juno?● API● The v3 API will be presented as a series of microversions to

v2 instead of a completely new API. The first of these microversions will be a v2.1 with stricter type checking.

● Clients will negotiate which microversions they support with the API servers, so backwards compatibility is maintained.

● Better support for cross project request ids is under way● Better tagging support in EC2

Where are we going in Juno?● Scheduler● There is work underway to allow us to split out the scheduler

into its own service that other projects can use as well. We need to rearrange a fair bit of code to enable this though.

Where are we going in Juno?● SQL Database● Support for DB2 as a SQL database is proposed.

Where are we going in Juno?● libvirt driver● Support for starting LXC containers from a block device● Use of libvirt storage pools● NFV enabling features, including:● PCI-SRIOV passthrough support● NUMA aware scheduling

Where are we going in Juno?● vmware driver

● Refactoring of driver code to make it more maintainable

● Support for:

● hot plug network interfaces

● ephemeral disks

● vSAN data stores

● booting OVA images

Questions?