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! >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
