Open Stack

confirmed

On 04/03/2014 03:44 PM, James Slagle wrote:
> 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!
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140403/a6939ae3/attachment.pgp>