+1
On Fri, Sep 20, 2013 at 10:12 AM, Russell Bryant <[email protected]> wrote: > Greetings, > > I would like to run for the OpenStack Compute (Nova) PTL position. > > I am the current Nova PTL. I have been working on OpenStack since late > 2011 and have been primarily been focused on Nova since then. I would > love to continue in this position to help drive the Nova project > forward. > > Quite a bit of work goes into the PTL position beyond specific technical > work: > > https://wiki.openstack.org/wiki/PTLguide > > Most of what I will focus on in this message are the things that I have > done and would like to do that go beyond technical topics. > > > * Havana > > The Havana release is the first release where I served as the Nova PTL. > I feel that Havana has been a successful development cycle for us so > far. You can find record of our progress toward the Havana release on > each of the milestone pages: > > https://launchpad.net/nova/+milestone/havana-1 > https://launchpad.net/nova/+milestone/havana-2 > https://launchpad.net/nova/+milestone/havana-3 > https://launchpad.net/nova/+milestone/havana-rc1 > > As the PTL, I led the creation of the design summit schedule for the > Nova track, as well as the majority of the blueprint handling for the > release roadmap. > > For Icehouse, I expect this process to be largely the same, but I would > like to involve more people in prioritizing design summit sessions, as > well as reviewing blueprints. > > > * Code Review Process > > The PTL of Nova is certainly not the only technical leader in > the project. There is a team of technical leaders, the nova-core team, > responsible for processing the high volume of code review requests we > receive. A key responsibility of the Nova PTL is to ensure that the > nova-core team has the right people on it at the right time. > > To that end, I have started doing some things in the last release cycle > to help with managing the core team. The first is starting to document > core team expectations: > > https://wiki.openstack.org/wiki/Nova/CoreTeam > > The second is gathering metrics around the core activity of the team: > code reviews: > > http://russellbryant.net/openstack-stats/nova-reviewers-30.txt > http://russellbryant.net/openstack-stats/nova-reviewers-90.txt > http://russellbryant.net/openstack-stats/nova-reviewers-180.txt > > The Nova project has seen an ongoing increase in contributions. As a > result, there have been some complaints about review times. It has been > a priority of mine to get a handle on this from a project management > perspective. The first step here was to start collecting metrics on > review times, which you can find here: > > http://russellbryant.net/openstack-stats/nova-openreviews.html > > Using these metrics, I can also compare how the Nova project's review > team is doing compared to other OpenStack projects. > > http://russellbryant.net/openstack-stats/all-openreviews.html > > Now that we have this information, we have been able to set goals and > make changes based on real data. > > You can find the code for generating all of these stats here: > > http://git.openstack.org/cgit/openstack-infra/reviewstats > > As for the future, I think there are some obvious improvements that > could be made. The biggest is that I think there is room to add more > people to the review team when the opportunity presents itself. I would > also like to have another discussion about the future of compute > drivers, and whether maintainers of some drivers would rather have their > own repository. I expect to have a design summit session on this topic: > > http://summit.openstack.org/cfp/details/4 > > > * Sub-project Leadership > > One thing that is very apparent to me is that given the Nova project's > size, I think there are too many things for one person to carry. There > are multiple great people in the Nova community that step up regularly > to make things happen. I think we should start looking at creating some > official sub-project leadership roles. Here are some ideas with some > potential responsibilities: > > - python-novaclient lead > - have a vision for python-novaclient > - review all novaclient patches > - ensure that novaclient blueprints get reviewed and bugs are triaged > - build and lead a group of people interested in novaclient > > - nova bug triage lead > - ensure bugs are triaged > - ensure the highest priority bugs are discussed, either on the > mailing list or in the weekly nova meeting > - generate metrics on nova bugs > - set goals for nova bug processing, and track our progress against > the goals using the generated metrics > - build and lead a group of people interested in helping nova by > doing bug triage > > - nova-drivers team > - (This actually already exists, but I think we could formalize > responsibilities and make more use of it) > - responsible for reviewing nova blueprints > - ensure all blueprints have appropriate design documentation and fit > within the overall project vision > - regularly discuss blueprints with each other and the overall nova > community via the mailing list and weekly meeting to ensure Nova > has an accurate and high quality roadmap > > These positions could either be elected by the technical contributors to > the Compute program (we sure love elections around here), or they could > simply be appointed by the PTL (my preference, I think). > > > * What do you think? > > Finally, I would like to know what you all think. What does the project > need to improve on? > > What could I improve on if I were to be re-elected as the PTL? > > > * Technical Matters > > I've used most of this message to focus on non-technical matters. That > certainly does not mean that I do not have strong opinions on the > technical future of Nova. In fact, I feel strongly that we need to > continue to invest heavily in these areas: > > 1) Upgrades > 2) Scale > 3) Security > > Upgrades - We have made ongoing progress towards supporting live rolling > upgrades over the last few releases. We need to continue to push hard > on this. > > http://summit.openstack.org/cfp/details/94 > > Scale - Nova is already being deployed at very large scale (10s of > thousands of nodes). However, there are definitely pain points. I'd > like to see more people working on cells support. Even within a cell > there are things we could improve. For example, I'd like to see more > progress toward supporting more scalable messaging, either by adding > support for AMQP 1.0 which supports peer-to-peer messaging as well as > brokered, or by continuing to enhance the existing ZeroMQ support. > Enhancements to our database usage to make it more scalable are > important, as well. > > Security - This is a priority for anyone deploying OpenStack, but > especially in a public setting. One area we have had in our sights for > a while is the use of trusted messaging. The infrastructure for this > should be merged early Icehouse, so I'd like to see Nova adopt it and > start making use of it as soon as possible. > > > * Other References > > My patches: > https://review.openstack.org/#/q/owner:[email protected],n,z > > My reviews: > https://review.openstack.org/#/q/reviewer:[email protected],n,z > > Activity Board: > > http://activity.openstack.org/data/display/OPNSTK2/Technical+Contributors > > http://activity.openstack.org/data/pages/viewpage.action?pageId=3670022 > > Ohloh profile: > https://www.ohloh.net/accounts/russellb > > > *** > > I have had a blast working on OpenStack. It is truly an honor to work > with so many talented people and to have been elected to help lead the > effort. > > Thank you for your consideration, > > -- > Russell Bryant > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Ravi
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
