Open Stack

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

First, a little about myself. I've been involved with OpenStack and
contributing to TripleO for nearly a year now. I'm currently a developer at Red
Hat and I've spent much of my career before OpenStack working on various
systems management tools. Working on Red Hat's Satellite and RHUI offerings
and rPath's rBuilder are where I've done most of my Python, API, and database
development in the past.

To me, the PTL role is about facilitating developers to work on what they want
to work on. I see that as the best way to bring in new developers and increase
our number of contributors. That being said, not everything can fit under the
TripleO umbrella. So, the role of the PTL also should be in assisting in
decisions about the direction of the project in a way that is best for TripleO
and OpenStack as a whole. The PTL role is also an organizational role. Not just
in the day to day tasks, but also in helping to make sure folks are aware of
what others are working on.  Also, encouraging collaboration towards common
goals, maintaining a common focus, and building consensus for the project are
also important.

Many of the contributions that I've made to TripleO to date have been about
broadening support for different use cases and adding to stability. When I
first got involved, I focused primarily on getting TripleO working really well
on Fedora and doing a lot of bug fixing and enablement in that area. In doing
so, I've aimed to do it in a way so that it's easier for the next person coming
along who might like to try something new. I've also championed things like
package install support and stable branches for some of our projects.
Additionally, I have aimed to make TripleO easier for newcomers and developers.

During the Juno cycle, if elected as PTL, I think that TripleO should continue
to focus on many of the same areas that are focal points today. These items are
critical to the success and real world usage of TripleO. The 3 biggest items to
me are:

- Improving our CI infrastructure to where TripleO is voting and in the gate
- HA deployments
- Upgrades
- Tuskar

I'd like to see Tuskar continue to develop to the point where it is ready to be
integrated into TripleO more directly. Specifically, a devtest path that uses
Tuskar, CI jobs that use Tuskar, and generally driving folks towards trying and
providing feedback on the Tuskar work flow.

In addition though, I'd like to focus on some other overarching themes that I
think are important to the project. If elected, my additional goals for the
TripleO project would be to work to broaden it's adoption and increase
contributions.

The first of these is further enablement of alternative implementations. I
would like to see TripleO as broadly adopted as possible, and I think that a
"one size fits all" approach may not be the best way.  To date, I think TripleO
has done a good job enabling folks to do alternative implementations as long as
there are people willing to step up and do the work. I would continue that
sentiment, but further it some as well by really trying to open the doors for
new developers.

To that end, I'd like to focus on easier developer setups, even if that means
leaving out important pieces of the TripleO process for the sake of giving some
people an easier way to get bootstrapped. Folks that want to work on support
for their favorite configuration management tool, or additional package support,
or additional distro support, don't necessarily have to have a complete
functional TripleO environment with all the bells and whistles.

Secondly, I think we as a community could have some better examples of how
different tools might fit into existing processes, and perhaps even bootstrap
these implementations to a degree. The puppet-openstack is one such effort I'd
like to see have some integration with TripleO.

Thirdly, similar to making things easier for developers, I'd like to make things
easier for operators to try and use TripleO. I think getting real world
operator feedback for TripleO is critical, especially as we are in the process
of defining it's future direction. Some specifics in this area would include
ability to adopt deployments that might be deployed via pre-existing tooling,
integration with existing deployed configuration management solutions, or
ways to integrate with existing upgrade mechanisms (possibly via HOT).

Finally, I'd like to see TripleO become a true default installer for OpenStack.
I'd like to see an implementation of elements that are not image specific, and
instead are the reference implementations of how an OpenStack project gets
installed and configured. I think there is a lot of opportunity to reduce and
reuse code here across projects in this space. Many projects document how they
should be installed, then there are implementations in devstack, and also
implementations now in TripleO.  I'd like to see the elements become more
universal to where they could be used outside of an image building context and
perhaps even in devstack. tripleo-image-elements then just becomes additional
image specific logic for TripleO that can be layered on top of the install
elements.

My commits: https://review.openstack.org/#/q/owner:slagle,n,z

My reviews: https://review.openstack.org/#/q/reviewer:slagle,n,z

http://www.russellbryant.net/openstack-stats/tripleo-reviewers-180.txt

Thank you for your consideration!

-- 
-- James Slagle
--