Michael Still, Compute PTL, outlines the changes made in the Icehouse release as well as upcoming updates for Juno.
Learn more about Compute (Nova) here: https://wiki.openstack.org/wiki/Nova
3. 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
4. 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
5. 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
6. 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.
7. 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
8. 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
9. 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
10. 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.
11. 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
12. 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.
13. Where are we going in Juno?
● SQL Database
● Support for DB2 as a SQL database is proposed.
14. 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
15. 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