Open Stack

I'd like to announce my candidacy for TripleO PTL.

I think most folks who have worked in the TripleO community probably know me.
For those who don't, I work for Red Hat, and over the last year and a half that
I've been involved with TripleO I've worked in different areas. My focus has
been on improvements to the frameworks to support things such as other distros,
packages, and offering deployment choices. I've also tried to focus on
stabilization and documentation as well.

I stand by what I said in my last candidacy announcement[1], so I'm not going
to repeat all of that here :-).

One of the reasons I've been so active in reviewing changes to the project is
because I want to help influence the direction and move progress forward for
TripleO. The spec process was new for TripleO during the Juno cycle, and I also
helped define that. I think that process is working well and will continue to
evolve during Kilo as we find what works best.

The TripleO team has made a lot of great progress towards full HA deployments,
CI improvements, rearchitecting Tuskar as a deployment planning service, and
driving features in Heat to support our use cases. I support this work
continuing in Kilo.

I continue to believe in TripleO's mission to use OpenStack itself.  I think
the feedback provided by TripleO to other projects is very valuable. Given the
complexity to deploy OpenStack, TripleO has set a high bar for other
integrated projects to meet to achieve this goal. The resulting new features
and bug fixes that have surfaced as a result has been great for all of
OpenStack.

Given that TripleO is the Deployment program though, I also support alternative
implementations where they make sense. Those implementations may be in
TripleO's existing projects themselves, new projects entirely, or pulling in
existing projects under the Deployment program where a desire exists. Not every
operator is going to deploy OpenStack the same way, and some organizations
already have entrenched and accepted tooling.

To that end, I would also encourage integration with other deployment tools.
Puppet is one such example and already has wide support in the broader
OpenStack community. I'd also like to see TripleO support different update
mechanisms potentially with Heat's SoftwareConfig feature, which didn't yet
exist when TripleO first defined an update strategy.

The tripleo-image-elements repository is a heavily used part of our process and
I've seen some recurring themes come up that I'd like to see addressed. Element
idempotence seems to often come up, as well as the ability to edit already
built images. I'd also like to see our elements more generally applicable to
installing OpenStack vs. just installing OpenStack in an image building
context.  Personally, I support these features, but mostly, I'd like to drive
to a consensus on those points during Kilo.

I'd love to see more people developing and using TripleO where they can and
providing feedback. To enable that, I'd like for easier developer setups to
be a focus during Kilo so that it's simpler for people to contribute without
such a large initial learning curve investment. Downloadable prebuilt images
could be one way we could make that process easier.

There have been a handful of mailing list threads recently about the
organization of OpenStack and how TripleO/Deployment may fit into that going
forward. One thing is clear, the team has made a ton of great progress since
it's inception. I think we should continue on the mission of OpenStack owning
it's own production deployment story, regardless of how programs may be
organized in the future, or what different paths that story may take.

Thanks for your consideration!

[1] http://lists.openstack.org/pipermail/openstack-dev/2014-April/031772.html


-- 
-- James Slagle
--