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.
Deployability
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 : [email protected]
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
