<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">After reading Thierry's blog post on what he expects from the Nova PTL, I started to consider what I think the PTL's job should be. As I see it, a Project Technical Lead has three main responsibilities:<br><br><b>* Internal Project Communication</b><br><i> - minimize duplication of work<br> - facilitate collaboration between diverse teams<br> - ensure resources are evenly allocated to meet release requirements</i><br><b>* OpenStack Project Integration</b><br><i> - improve integration with other OpenStack components<br> - ensure the project is contributing to and using openstack-common<br> - help break out components into separate projects when needed</i><br><b>* Long-Term Project Vision</b><br><i> - verify development meets basic design tenets<br> - make sure that project is actually deployable and usable<br> - maintain alignment between release requirements and long term goals</i><br><br>I'd like to explain my position on these responsibilities, why they are important, and how I see that they can be best fulfilled by a Project Technical Lead in Nova. Obviously, the many specifics will be influenced by the design summit, but this should paint a picture of what I think is a good starting point for the future of Nova. This isn't meant to be an exhaustive list, but rather a beginning. Hopefully, my ideas can spark a bit of discussion to give the elected PTL a clear idea of what to expect.<br><br><div><br><b>Internal Project Communication</b><br><br>One of the most important jobs of the Nova PTL is to facilitate communication between the various teams that are working on the Nova code base. The amount of different work going into Nova is already hard to track, and this will only become more difficult as more organizations and groups join. The PTL needs to keep track of which teams are working in which areas, to ensure that the teams are able to communicate with each other, and to verify that the teams are keeping their specs and blueprints up to date.<br><br>To facilitate this, it seems vital to know who is on which team and their main development focus for the current release. Because it will be virtually impossible to track everyone individually, it will help for him or her to have a point of contact on each team. He should also attempt to facilitate different teams working together if their development goals align.<br><br>A good example of a place that could benefit from attention by the PTL, is the oft-mentioned network refactor. It has been progressing slowly because there are diverse teams working on it without sufficient coordination. The PTL could help to organize a combined network team and help to select a team lead to drive the refactor.<br><br></div><div><br><b>OpenStack Project Integration</b><br><br>Another responsibility of the PTL is to make sure that Nova is well-integrated with the other openstack components. The PTL needs to have a clear picture of new and needed features in glance and swift, as well as any new projects that are added to OpenStack.<br><br>It is also vital that we focus on common components over the next couple releases. If we don't do this the projects will gradually grow apart, and it will be very difficult to present a coherent OpenStack deployment involving all of the projects. The most important first-step in my mind is Authn/Authz. A common authentication system will do wonders for keeping the projects aligned.<br><br>We have discussed beginning to break out components in the Diablo time frame. We need to focus very early on the changes necessary to make this painless. This includes minimizing the communication between compute, network, and volume, and ensuring that the components are using clear interfaces.<br><br></div><div><br><b>Long Term Project Vision</b><br><br>Finally, the PTL needs to maintain a holistic vision of the project and the long term vision. This has less to with the technical implementation details, and more to do with making sure the project is successful and of high quality. The PTL needs to constantly be asking two quesions:<br><br> 1) Is it deployable?<br> 2) Is it usable?<br><br>For the project to succeed, we need a vehement yes to both of these. With the various groups working on features that are important to them, it is easy to forget that the it is the quality of the project that will determine the success or failure of OpenStack as a whole. We must put extra focus in the following four areas:<br><br><u>Automated Testing</u><br><br>Automated Testing is the only way we can verify that we have a working system. There should be multiple configurations that are being automatically tested and a set of instructions for creating test clusters and new configurations.<br><br><u>Code Consistency</u><br><br>We must spend time cleaning up pylint scores and vetting the unit tests and various parts of the code for common style. We need a clear developer guide and toolset configuration examples for new developers. These will allow new developers become productive more quickly.<br><br><u>Deployability</u><br><br>We need more focus on documentation, tools, and recommended (tested) configurations of hardware and software. This absolutely needs to include integrated deployments that incorporate other OpenStack components.<br><br><u>User Experience</u><br><br>Testing of actual use cases is very important to make sure that the user-experience doesn't suffer. It is also important that we understand and synthesize customer needs as organizations continue to deploy OpenStack. There are a number of features that are very valuable to users that aren't completeley obvious to developers (snapshotting is a good example of this).</div></body></html>