Open Stack

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
> 
> 


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