Open Stack

I am writing to announce my candidacy for OpenStack Deployment PTL.

Those of you involved with the deployment program may be surprised to
see my name here. I've been quiet lately, distracted by an experiment
which was announced by Allison Randal a few months back. [1]

The experiment has been going well. We've had to narrow our focus from
the broader OpenStack project and just push hard to get HP's Helion
Product ready for release, but we're ready to bring everything back out
into the open and add it to the options for the deployment program. Most
recently our 'tripleo-ansible' repository has been added to stackforge [2],
and I hope we can work out a way where it lands in the official deployment
namespace once we have broader interest.

Those facts may cause some readers to panic, and others to rejoice,
but I would ask you to keep reading, even if you think the facts above
might disqualify me from your ballot.

My intention is to serve as PTL for OpenStack Deployment. I want to
emphasize the word "serve". I believe that a PTL's first job is to serve
the mission of the program.

I have watched Robert serve closely, and I think I understand the wide
reach the program already has. We make use of Ironic, Nova, Glance,
Neutron, and Heat, and we need to interface directly with those projects
to be successful, regardless of any other tools in use.

However, I don't think the way to scale this project is to buckle down and
try to be a hero-PTL. We need to make the program's mission more appealing
to a greater number of OpenStack operators that want to deploy and manage
OpenStack. This will widen our focus, which may slow some things down,
but we can collaborate, and find common ground on many issues while still
pushing forward on the fronts that are important to each organization.

My recent experience with Ansible has convinced me that Ansible is not
_the_ answer, but that Ansible is _an_ answer which serves the needs
of some OpenStack users. Heat serves other needs, where Puppet, Chef,
Salt, and SSH in a for loop serve yet more diverse needs.

So, with that in mind, I want to succinctly state my priorities for
the role:

 * Serve the operators. Our feedback from operators has been extremely
   mixed. We need to do a better job of turning operators into OpenStack
   Deployment users and contributors.

 * Improve diversity. I have been as guilty as anyone else in the past
   of slamming the door on those who wanted to join our effort but with
   a different use case. This was a mistake. Looking forward, the door
   needs to stay open, and be widened. Without that, we won't be able
   to welcome more operators.

 * March toward a presence in the "gate". I know that "the gate" is
   a hot term and up for debate right now. However, there will always
   be a gate of some kind for the projects in the integrated release,
   and I'd like to see a more production-like test in that gate. From
   the beginning, TripleO has been focused on supporting continuous
   deployment models, so it would make a lot of sense to have TripleO
   doing integration testing of the integrated release. If there is
   a continued stripping down of the gate, then TripleO would still
   certainly be a valuable CI job for the integrated release. We've had
   TripleO break numerous times because we run with a focus on production
   ready settings and multiple nodes which exposes new facets of the
   code that go untouched in the single-node simple-and-fast focused
   devstack tests.
   
   Of course, our CI has not exactly been rock solid, for various
   reasons. We need to make it a priority to get CI handled for at least
   the primary tooling, and at the same time welcome and support efforts
   to make use of our infrastructure for alternative tooling. This isn't
   something I necessarily think will happen in the next 6 months, but
   I think one role that a PTL can be asked to serve is as shepherd of
   long term efforts, and this is definitely one of those.

So, I thank you for taking the time to read this, and hope that whatever
happens we can build a better deployment program this cycle.

-Clint Byrum

[1] http://lists.openstack.org/pipermail/openstack-dev/2014-August/042589.html
[2] https://git.openstack.org/cgit/stackforge/tripleo-ansible