<div dir="ltr"><div class="gmail_default" style="font-family:'courier new',monospace">Hello Everybody,</div><div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">

I would like to run for election as Cinder PTL for the upcoming I release.  </div><div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">

For those who don't know me, I am the current Cinder PTL and have been working on OpenStack for almost two years now.  Most of that time has been spent leading the Cinder efforts starting with the separation of the Nova-Volume code.  The upcoming Havana release will mark our third release with Cinder as a released project in OpenStack and I think we have continued to grow and get better with each release, Havana being no exception.</div>

<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">Some of you may know that there's a lot that goes in to being a PTL.  I see it as a combination of Project/Team management, Technical Leadership and Evangelism.  I love the job, every aspect of it as well as the challenges that come with it.  This includes talking about Cinder, brainstorming new ideas and *recruiting* new vendors and contributors.</div>

<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">Given Cinders unique plugin model (we now have over 17 supported back end device drivers), one of the biggest challenges is continuing to provide and maintain a feature equivalent and robust reference implementation as well as maintaining consistent behaviors across all of these drivers.  At the same time we've provided ways for different vendors to expose their own unique features via optimizations or the use of types and extra-specs.  The mantra here has been, if vendor A wants to implement a new feature there has to be a way to implement it across the board.  It may not be the most elegant or efficient for some back-ends, but the idea is you will have consistent capabilities and behaviors.  One of the things that I think makes the above described philosophy so powerful is that it drives interest and contributions to the project as a whole.  The result is that Cinder has multiple contributors from competing storage vendors all driving to advance the overall project for EVERYBODY.  I think we've done a fantastic job in this respect and if elected I plan to continue to drive this as one of the main ideologies for the project.</div>

<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">There are a number of things that I see as needing particular focus during the upcoming release, and if elected I will try and drive these items:</div>

<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">1. Functional test qualification for back end devices</div>

<div class="gmail_default" style="font-family:'courier new',monospace">Many of you have heard about this via mailing list, but I think it's critical that we have some way to share publicly that the drivers that are shipped with cinder actually work.  This is something that I've started and plan to implement for the I release, it will start simply by requiring that all of the tests we currently run in the CI gates are run against each driver/back-end and the results of those runs are submitted publicly.<br>

</div><div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">2. More involvement in Horizon</div><div class="gmail_default" style="font-family:'courier new',monospace">

This has been something that I've thought of and mentioned in the past but it hasn't really happened.  For the upcoming release I would like to drive folks that implement new features in Cinder to help contribute and get those same features exposed in Horizon.  In my opinion OpenStack is growing so quickly and becoming so large, that there needs to be more contribution from all projects to keep Horizon updated.  I'm not saying something as extreme as to have a rule that a BP is not closed/implemented until the Horizon work is done, but I'd love to see folks have that sort of view (un-enforced norm in terms of behaviors) with features they implement in Cinder as we go forward.</div>

<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">3. Organization and strategy around common libraries for Block Storage</div>

<div class="gmail_default" style="font-family:'courier new',monospace">This is something that we talked about during the last summit and we made some progress on.  The problem is that it started to grow in to it's own beast and I think we lost our focus.  I'd like to really emphasize early in the Icehouse release what our common goals and objectives are here and make this a reality early on in the release cycle (preferably the first milestone).</div>

<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">4. Continued implementation of task-flows and states</div>

<div class="gmail_default" style="font-family:'courier new',monospace">We've made a good initial start here by adopting task-flows for our volume-create process.  I think there's a lot more that can be done to improve upon what we have here, and also to spread that out to the other Cinder tasks.</div>

<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">5. More interaction with the other projects</div><div class="gmail_default" style="font-family:'courier new',monospace">

The worst thing for any project in OpenStack in the coming release IMO is going to be working in isolation.  There are a large number of new projects/programs being introduced, many of which that utilize bits and pieces of all OpenStack projects.  I think it's critical that we come up with some ways to collaborate across projects and programs, not only for better implementations in consumer projects, but also to make sure we provide valuable features that might be needed.  This particularly includes projects like Trove, Ironic and Triple'O.</div>

<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">6. Continue to grow the contributing community</div>
<div class="gmail_default" style="font-family:'courier new',monospace">
This is key IMO for any Open Source project, we need to continue to grow the interest and contributions.  Whether that be via new drivers/vendor participation or new core features, I believe involvement and particularly community growth is a critical measure of a projects health.</div>

<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">There are a number of other things on my list, but these are the main driving philosophies that I'd propose in Cinder for the next release cycle.  If you have any questions for me, or there are specific concerns or omissions from this list don't hesitate to send an email or grab me on IRC.  I'm happy to share my opinions and ideas and clarify anywhere that I can.</div>

<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">Thanks,</div><div class="gmail_default" style="font-family:'courier new',monospace">

John</div><div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">

<br></div><div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace"><br></div></div>