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:rbry...@redhat.com,n,z My reviews: https://review.openstack.org/#/q/reviewer:rbry...@redhat.com,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 OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev