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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev