Jump to: navigation, search




Official name OpenStack Compute
Source code https://github.com/openstack/nova
Bug tracker https://bugs.launchpad.net/nova
Feature tracker https://blueprints.launchpad.net/nova
Developer doc http://docs.openstack.org/developer/nova/

We align with what was the integrated release schedule, with three milestones. For Mitaka this means: Mitaka_Release_Schedule

But we do have some Nova specific process deadlines, please see Nova/Mitaka_Release_Schedule and Nova/Process

Python Nova client

Source code https://github.com/openstack/python-novaclient
Bug tracker https://bugs.launchpad.net/python-novaclient
Feature tracker https://blueprints.launchpad.net/python-novaclient


  • PTL
    • John Garbutt (johnthetubaguy)
  • Feature Drivers
  • Code Reviewers
  • Blueprint Czar (responsible for maintenance of Nova's blueprint lists)
    • TBC
  • Bug Czar (responsible for organizing Nova's bug team that maintains Nova's bug list)
    • Markus Zoeller (markus_z)
  • Stable Branch Czar (works with stable maintenance team around Nova things)
    • Matt Riedemann (mriedem)
  • Security Czar (responsible for working with VMT and leading nova-coresec)
    • Michael Still (mikal)
  • Gate Czar (on top of the status of Nova in the CI gate)
    • Matt Riedemann (mriedem)
  • APAC/US Meeting Czar (runs the 2100 UTC Nova meeting)
    • Michael Still (mikal)
  • API Working Group Liaisons
    • Alex Xu (alex_xu)
  • Ironic Liaison
    • John Villalovos (jlvillal)
    • Michael Davies (mrda) (backup)
  • python-novaclient Czar
    • TBC
  • Mentoring Czar
    • John Garbutt (johnthetubaguy)
  • Answers Czar
  • Release Czar
    • TBC
  • Docs Czar
    • TBC

For bug tag owners, please see: Nova Bug Triage

For other folks, please see: Cross Project Liaisons (CPLs)

General Resources


Release Process

  • Nova releases are now done by providing the Release Manager with a git SHA to tag
  • Client releases are done by following Nova/Client Release Process

Other resources

Resources for Contributors

Contributor Documentation

Nova subteams

The Nova team meets weekly: Meetings/Nova.

In addition to a project-wide Nova gathering each week, there are some sub-teams. These sub-teams get together to discuss work going on in a focused area of Nova.

Code Review Subteam

Subteams don't need permission. They can be around for short or long periods of time.

A common patter is an adhoc group of people, focusing on a sub set of reviews. They generally co-ordinate on here: https://etherpad.openstack.org/p/mitaka-nova-priorities-tracking

For each subteam, the etherpad usually includes:

  • list of people in the group (IRC nics)
  • list of patches the sub team have reviewed, and think are ready for nova-core to approve
  • list of patches the sub team are focusing their reviews on
  • May link to a regular meeting, but that is strictly optional

Over time, it is hoped, some subteams may become trusted enough to could as a +2. Even without counting as a +2, the review focus, and implied prioritisation is still very valuable.

Sub-team Meetings

Some subteams are more formal, with a regular meeting and a wiki page.

  • The linked wiki page should include:
    • The mission of the team
    • A regular meeting time
    • A coordinator / point of contact
    • Meeting Agenda
    • Links to logs from previous meetings
  • A sub-team representative should regularly attend the main Nova meeting to provide a sub-team status report.
  • A sub-team is *not* exclusively responsible for an area of code. Anyone is welcome to contribute anywhere. However, you are encouraged to communicate regularly with others working in the same area as you and sub-teams help encourage that.
  • A sub-team is about organizing development efforts, but not necessarily setting direction for the project in a given area. Approval of patches is still done by the nova-core team and it is beneficial to publish designs to the openstack-dev mailing list for vetting in advance.
Active Sub-teams:

TODO - this list is very out of date, need a better approach.


  • Previous PTLs
    • Vish Ishaya (vishy), project beginning until Grizzly release
    • Russell Bryant (russellb), Havana and Icehouse releases
    • Michael Still (mikal), Juno and Kilo releases
    • John Garbutt (johnthetubaguy), Liberty and Mitaka releases
  • Previous or current core reviewers:
    • Andrew Laski
    • Brian D. Elliott
    • Brian Lamar
    • Brian Waldon
    • Chris Behrens
    • Chris Yeoh
    • Dan Prince
    • Dan Smith
    • Daniel Berrange
    • Devananda van der Veen
    • Jay Pipes
    • Joe Gordon
    • Johannes Erdfelt
    • John Garbutt
    • Ken'ichi Ohmichi
    • Kevin L. Mitchell
    • Lorin Hochstein
    • Mark McLoughlin
    • Matt Dietz
    • Matt Riedemann
    • Melanie Witt
    • Michael Still
    • Nikola Dipanov
    • Pádraig Brady
    • Paul Voccio
    • Rick Harris
    • Russell Bryant
    • Sandy Walsh
    • Sean Dague
    • Soren Hansen
    • Trey Morris
    • Vishvananda Ishaya
    • Yun Mao

Developer Contacts

Work In Progress The following is a list of major subsystems within Nova and people that you can approach on IRC or email if you have questions about that particular subsystem. IRC nicks are in parentheses.

Nova Objects Framework

- Dan Smith (dansmith)
- Jay Pipes (jaypipes)

libvirt virt driver

- Dan Berrange (danpb)

Hyper-V virt driver

- Claudiu Belu (claudiub)

VMWare/vCenter virt driver

- Gary Kotton (garyk) 
- Radoslav Gerganov (rgerganov)

XenAPI virt driver

- Bob Ball (BobBall)
- John Garbutt (johnthetubaguy)

Ironic/bare metal

- Devananda van der Veen (devananda) 

Scheduling and resource tracking

- Sylvain Bauza (bauzas) 
- Jay Pipes (jaypipes) 

Block device mapping and volume attachments

- Nikola Dipanov (ndipanov) 


- Sean Dague (sdague) 
- Alex Xu (alex_xu) 


- Andrew Laski (alaski) 

Cells (v1 and v2)

- Andrew Laski (alaski)
- Melanie Witt (melwitt)


- ?


-  Matt Riedemann (mriedem)

RPC and notification system

- Dan Smith (dansmith)

So, you want to learn more about Nova?

To learn more about Nova, please read out about Nova Mentoring