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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
