openstack team mailing list archive

[Eric Day <eday@xxxxxxxxxxxx>]

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.

-Eric

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.
> 
>    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     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp