openstack team mailing list archive
Mailing list archive
Re: Thoughts on the Nova PTL
Well said Vish, this would be a great wiki entry for folks to reference
in the future. :)
While Nova probably needs the most coordination due to it's developer
base, these of course apply to all other projects.
On Tue, Mar 22, 2011 at 11:55:17PM -0700, Vishvananda Ishaya wrote:
> 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:
> * Internal Project Communication
> - minimize duplication of work
> - facilitate collaboration between diverse teams
> - ensure resources are evenly allocated to meet release requirements
> * OpenStack Project Integration
> - improve integration with other OpenStack components
> - ensure the project is contributing to and using openstack-common
> - help break out components into separate projects when needed
> * Long-Term Project Vision
> - verify development meets basic design tenets
> - make sure that project is actually deployable and usable
> - maintain alignment between release requirements and long term goals
> 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.
> Internal Project Communication
> 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.
> 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.
> 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.
> OpenStack Project Integration
> 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.
> 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.
> 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.
> Long Term Project Vision
> 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:
> 1) Is it deployable?
> 2) Is it usable?
> 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:
> Automated Testing
> 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.
> Code Consistency
> 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.
> 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.
> User Experience
> 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).
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp