confirmed On 24/09/14 05:19 PM, James Slagle wrote: > 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 > >
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
