Open Stack

Hi all!

I'd like to announce my candidacy to serve as a TC member.


About me:

I'm a software engineer at Red Hat, and have been working full-time on
OpenStack for the last two years.  I've been heavily involved with the Heat
project since before it was incubated, served as PTL for the Havana cycle,
and remain one of the top contributors to the project.

During Icehouse, I've been trying to improve my knowledge and involvement
with other projects, in particular contributing fixes to keystone and
working to improve Heat's functional testing via tempest.

Platform:

Working on orchestration provides a unique view of OpenStack - it's
essential to learn at least a little bit about every other project, because
orchestration integrates with everything.  This is an exciting challenge,
and provides a pretty broad perspective on issues such as API and client
consistency.

I am of the opinion that OpenStack should be inclusive by default and,
trademark considerations aside, should not be limited to a "core" of
components.  Instead I see OpenStack developing into an increasingly
powerful collection of abstractions, providing consistency for users and
flexibility for deployers.  If elected I would strive to work as an
advocate for new and recently graduated projects, seeking to identify
common problems and opportunities for improved integration.

The issues I would consider priorities were I to be elected are detailed
below, the common theme is basically better communication, efficiency and
reuse:

1. API consistency and reuse

I believe we're making great progress and improving API consistency but
there are still challenges and opportunities, primarily around improving
cross-project consistency, communication and reuse.  I see the TC's role
here as primarily one of facilitating and encouraging cross-project
discussion, providing direction and monitoring progress.

Closely related to this is encouraging projects to more pro-actively
collaborate via cross-project initiatives such as oslo.  Ultimately we all
benefit if we can reduce duplication of effort and collaborate on shared
solutions.

I believe that the TC should be providing clear leadership and direction
which encourages projects to avoid long term fragmentation as ultimately it
harms the user community (users operators and deployers getting
inconsistent experience) and developers (maintenance burden and lack of
knowledge transfer between projects).

Finally client API consistency should be improved, in particular working
towards common solutions for version discovery and common version-agnositc
interfaces which reduce the (IME considerable) pain users experience when
API versions change.

2. Mentoring of new projects

Having experienced the incubation process, and subsequent rapid growth of
the Heat project, I've got first-hand experience of the challenges
experienced by new projects seeking to become part of OpenStack.  There is
a lot of accumulated experience and knowledge in the community, and
in many cases this "lore" is not documented for new projects and
contributors.

I think the TC should strive to encourage more active mentoring of new
projects, by implementing a scheme where a representative from the
incubated project is paired with a person experienced with the area related
to a graduation requirement, over time this can lead to identifying areas of
common confusion, improved documentation, and hopefully engage new
contributors (and reviewers) to participate in components related to gate
integration and testing.

3. Review of current PTL model

After serving as the Heat PTL for Havana, I was left with the (apparently
not that uncommon) impression that there are aspects of the PTL role and
responsibilities which are sub-optimal for a diverse open-source project.

As such, I would propose a review of the current model, where a PTL's
primary function is release management and coordination, not really
technical leadership in many cases.

I would encourage consideration of a move to a "subsystem maintainer"
structure, similar to that used for the Linux kernel, where individual
projects and project sub-components are afforded more autonomy and less
granular management, in exchange for an increased requirement for
participation in automated gate integration testing.

There may be other alternative solutions, but I believe it's time to
initiate some discussion around what may be the most effective and
appropriate strategy for project release management and leadership in an
increasingly diverse and fast-moving environment.

Thanks for your consideration!

--
Steve Hardy
Red Hat Engineering, Cloud