2. Kilo - 2015.1.0
● Priority given to major architecture evolution
o http://specs.openstack.org/openstack/nova-specs/priorities/kilo-priorities.html
● Release of API v2.1
o https://dague.net/2015/06/05/the-nova-api-in-kilo-and-beyond-2/
● Reduced API downtime on Upgrade
o http://www.danplanet.com/blog/2015/06/26/upgrading-nova-to-kilo-with-minimal-downtime/
● Overall: 45 features, 525 bugs
o Libvirt hugepages, Hyper-V Gen 2 VM support, VMware vSAN support, and much more
o https://launchpad.net/nova/+milestone/2015.1.0
3. Plans for Liberty - 12.0.0
● Architectural evolution continues
o http://specs.openstack.org/openstack/nova-specs/priorities/liberty-priorities.html
o API v2.1 Improvements: v2.0 support, docs, client, drop extensions, policy
o Reducing upgrade downtime
o Making Cells v2 the default for all deployments (except cells v1 users)
o Increase development velocity, by further decoupling between components
● Many bugs and features in progress
o https://blueprints.launchpad.net/nova/liberty
o http://specs.openstack.org/openstack/nova-specs/specs/liberty/index.html
Note: Focus on reporting over prediction
4. Scaling the Nova Community
● Better communication: What and Why
o Work hard to stay Open, a clear mission and values, and clear current goals
o Make it easier to engage with the Nova community, and deal with growing pains
● Renewed Mentoring and Onboarding
o https://wiki.openstack.org/wiki/Nova/Mentoring
● Continued Innovation, within existing scope
o http://docs.openstack.org/developer/nova/project_scope.html
● Goal: Support Nova API ecosystem
● Goal: Stability, Scalability and Upgradability
5. Possible Future Priorities
● Feature Classification
○ More clarity around what is tested, and what is not
● Interoperability of Nova API
○ Flavor and Image metadata, Networking
● Big bug fix themes
○ Quotas, Cross Project Interactions
● Reliability and API Error Reporting (Tasks)
Editor's Notes
Agreed priorities at summit:
Nova has got too big, with components that are too tightly coupled, mostly due to very loose interfaces
Creating bugs that hurt users, and technical debt is slowing development
Better nova-scheduler interface (cross project scheduling), Mainstream Cells system
API v2.1:
easier to evolve, better discoverability, hard to use incorrectly
user requests specific version (above min) => isolate from changes
maintain v2.0 compatibility, eventually all APIs powered by single code base
Upgrade (normal to have no VM downtime, or connectivity downtime):
juno->kilo we did our first online database migration. Zero impact schema migrations and online-only data migrations
Release management focusing on reporting not prediction
Summit sessions gave priority to:
Continued work on architectural evolution
And Community Evolution (see next section)
We are always evolving, but during Liberty it’s time for a more focused effort
Miss match between intention and execution
Better comms:
strongly aligned, well established team => harder to join
Nova is really big, so its harder to get involved.
Ideally reduce scope: Cinder (layer below) and Heat (layer on top) are great examples
Users don’t want vendor lockin, Vender want users to easily adopt their technology, DefCore is helping
Upgrade from any commit: Live upgrade, API supported, but need to upgrade to each release, to drop compatibility code
Feature Classification:
Evolution of Hypervisor support matrix and Compute driver classification (A, B, C) but More API focused
Currently focused on how to evolve the API
Above work shines spotlight on APIs that are: incomplete or not interoperable
Our bug backlog shows some key themes
need to identify and address those head on
Biggest bug theme is general reliability (hurts upgrades)
Stability “Theater”: system has to feel stable.