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