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