Open Stack

Hi all,

I would like to run for the OpenStack Compute (Nova) PTL position.

Qualifications
-----------------
I have been working almost exclusively on Nova since mid-2012, and have
been on the nova-core team since late 2012. I am also a member of
nova-drivers, where I help to target and prioritize blueprints to help
shape and focus the direction of the project. I spend a lot of time
reviewing code from all over the Nova tree, and am regularly in the top
five reviewers:

  http://russellbryant.net/openstack-stats/nova-reviewers-90.txt

and I have sustained that level of activity consistently over time:

  http://russellbryant.net/openstack-stats/nova-reviewers-365.txt

My focus since I started has been on improving Nova's live upgrade
capabilities, which started with significant contributions to completion
of the no-db-compute blueprint, creation of the conductor service, and
most recently the concept and implementation for the NovaObject work. I
have been in or at the top of the list of contributors by commit count
for a few cycles now:


https://github.com/openstack/nova/graphs/contributors?from=2012-07-25&to=2014-03-22&type=c

  http://www.ohloh.net/p/novacc/contributors


http://www.stackalytics.com/?release=icehouse&metric=commits&project_type=openstack&module=&company=&user_id=danms

Icehouse Accomplishments
---------------------------------
This past cycle, I worked to get us to the point at which we could
successfully perform live upgrades for a subset of scenarios from Havana
to the Icehouse release. With the help of many folks, this is now a
reality, with an upstream gating test to prevent regressions going
forward. This is largely possible due to the no-db-compute and
NovaObject efforts in the past, which provide us an architecture of
version compatibility.

Late in the Icehouse cycle, I also worked with developers from Neutron
to design and implement a system for coordination between services. This
allows us to better integrate Nova's network cache and instance
modification tasks with Neutron's processes for increased reliability
and performance.

Looking forward to Juno
--------------------------------
Clearly, as Nova continues to grow, the difficult task of scaling the
leadership is increasingly important. In the Icehouse cycle, we gained
some momentum around this, specifically with involving the entire
nova-drivers team in the task of targeting and prioritizing blueprints.
The creation of the nova-specs repo will help organize the task of
proposing new work, but will add some additional steps to the process. I
plan to continue to lean on the drivers team as a whole for keeping up
with blueprint-related tasks. Further, we gained blueprint and bug czars
in John Garbutt and Tracy Jones, both of which have done an excellent
job of wrangling the "paperwork" involved with tracking these items. I
think that delegation is extremely important, and something we should
attempt to replicate for other topics.

The most tactile issue around scaling the project is, of course, the
review bandwidth and latency. Russell did a fantastic job of keeping
fresh blood on the nova-core team, which both encourages existing
members to exhibit a high level of activity, as well as encourages other
contributors to aim for the level of activity and review quality needed
to be on the core team. I plan to continue to look for ways to increase
communication between the core team members, as well as keep it packed
with people capable of devoting time to the important task of reviewing
code submissions.

Another excellent win for the Nova project in Icehouse was the
requirement for third-party CI testing of our virtualization drivers.
Not only did this significantly improve our quality and
regression-spotting abilities on virt drivers, but it also spurred other
projects to require the same from their contributing vendors. Going
forward, I think we need to increase focus on the success rate for each
of these systems which will help us trust them when they report failure.
Additionally, I think it is important for us to define a common and
minimum set of functions that a virt driver must support. Currently, our
hypervisor support matrix shows a widely-varying amount of support for
some critical things that a user would expect from a driver integrated
in our tree.

Thanks for your consideration!

--Dan