[openstack-dev] [OpenStack-Dev] Cinder PTL Candidacy

John Griffith john.griffith at solidfire.com
Tue Apr 1 19:02:02 UTC 2014

I'd like to announce my candidacy for the Block Storage (Cinder) PTL

I've been involved with OpenStack for about two and a half years now,
starting out by trying to help with some things in Nova-Volumes and then
with the help of a lot of great folks creating Cinder.  I have been the
unofficial and official PTL for Cinder since its beginning, and I've been
pretty passionate about the project, it's goals and it's evolution the
entire time.

There are a lot of different views about what a PTL "does", some
candidacies point out that it's not technical, others talk about delegation
and management.  I think that every project is different, and a lot of the
responsibility comes down to what sort of dedicated team of contributors
you have working on the project.  The role of PTL has requirements that are
well defined in item [1].  In addition however I think it's
the responsibility to step in and fill in the gaps if and when needed.
 This could be spending late nights debugging issues that slipped in to the
gate and wreak havoc on our process, or picking up the bugs that nobody
else wants to work on.  In my opinion the PTL is not only a Project Manager
and an Ambassador, but he or she is also a sort of pinch hitter on the
technical side.

Cinder has come a long way over the past year, not only the project, but
the team itself.  The maturity and growth of the project is visible from
the diverse group of dedicated folks we now have working on the project on
a regular basis.  We have greatly increased our number of reviewers as well
as contributors and while it's sometimes challenging we've maintained our
stance on API compatibility and feature implementation requirements for
all drivers.  The review and contribution stats(here [2] and here [3]) are
a clear indication that the project is actively growing and the work-load
is becoming more and more evenly distributed.  I personally think Cinder is
on the right track and the current direction is the right one to continue

All of that being said, there are still significant challenges ahead; the
top items I see for the Juno release:
* Maintaining driver compatibility
We've always taken a hard stance on requiring all submitted drivers to meet
a base set of requirements, this is extremely important for end users to
ensure the promise of OpenStack is realized.  It's rather difficult to pool
multiple block storage resources into a single virtual resource if some of
them don't implement the expected functionality.

* Quality and Performance
We've spent a good deal of effort on quality during the Icehouse release,
but I think there's still a lot of work to be done here.  In addition I
feel we should be starting to look at things like performance and
scalability of the core project itself.  We haven't done a lot of focused
work here in the past, and I think we should.

We also would benefit greatly from more in-depth testing being added to
Tempest as part of the CI process.  In particular we don't have much of the
scenario testing that's been introduced to some of the other projects to do
more stress and large-scale type operations.

* Processes to test storage backends
This has been somewhat controversial, but it really shouldn't be.  Once you
strip away the rhetoric and the strong opinions, at the end of the day I
would just like to see every driver in Cinder undergo and pass the same
tests that every commit runs against the LVMiSCSI driver.  It doesn't have
to be "everything" at once, but starting on this and getting data will help
to make Cinder and OpenStack a much stronger and healthier project.

* Configuration and Management improvements
This is something that has a lot of potential in my opinion.  Cinder isn't
the most difficult project to set up and manage, however it does have a
daunting number of options, and ever growing number of choices in
components and many of them aren't well understood.  I'd like to see
easier, more clear configuration options, the ability to do things like
"plug and play" driver/backend addition etc.

* Tighter integration and collaboration with other OpenStack projects
This is a big one in my opinion as the number of projects in OpenStack
continues to grow at an exponential rate.  We as the Cinder team should do
a much better job of tying in with other groups, not only the obvious like
Nova, but also Ceilometer, Trove, Savannah and of course Horizon.

Our logging and exception handling also still needs a good deal of work.
 I've spent a lot of time this release inspecting logs and debugging issues
and I'm afraid we don't make things very easy for folks that are actually
deploying OpenStack and trying to use the logs to debug issues.

I've had a few people approach me and ask if I thought it would be good if
I were to "not" run;  in my case I still feel that I have a good deal to
offer and I'd like to continue doing the work.  I'm relying more and more
on other contributors in the community which makes a huge difference.
 Every project is different, how it's run, how decisions are made etc.  In
the case of Cinder, I don't think there's an uneven balance of decision
making or direction planning in Cinder (in other words I think there's
broad inclusion of multiple members); those responsibilities are shared
well across the entire team which in my opinion makes all the difference in
the world.

In summary, it's been an absolute privilege to serve as PTL for Cinder, I
love the project and truly enjoy the work.  I'm hoping that others feel as
though I've done a good job here and would like to see me continue in this
role.  I realize that it's more and more common now for folks to step down
as PTL after a couple of releases, it can be a stressful job and it's good
to share the work-load.


[1]: https://wiki.openstack.org/wiki/PTLguide
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140401/b87ea124/attachment.html>

More information about the OpenStack-dev mailing list