Open Stack

confirmed

On 03/28/2014 10:07 AM, Dan Smith wrote:
> 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
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>