Open Stack

confirmed

On 24/09/14 04:03 AM, Clint Byrum wrote:
> I am writing to announce my candidacy for OpenStack Deployment PTL.
> 
> Those of you involved with the deployment program may be surprised to
> see my name here. I've been quiet lately, distracted by an experiment
> which was announced by Allison Randal a few months back. [1]
> 
> The experiment has been going well. We've had to narrow our focus from
> the broader OpenStack project and just push hard to get HP's Helion
> Product ready for release, but we're ready to bring everything back out
> into the open and add it to the options for the deployment program. Most
> recently our 'tripleo-ansible' repository has been added to stackforge [2],
> and I hope we can work out a way where it lands in the official deployment
> namespace once we have broader interest.
> 
> Those facts may cause some readers to panic, and others to rejoice,
> but I would ask you to keep reading, even if you think the facts above
> might disqualify me from your ballot.
> 
> My intention is to serve as PTL for OpenStack Deployment. I want to
> emphasize the word "serve". I believe that a PTL's first job is to serve
> the mission of the program.
> 
> I have watched Robert serve closely, and I think I understand the wide
> reach the program already has. We make use of Ironic, Nova, Glance,
> Neutron, and Heat, and we need to interface directly with those projects
> to be successful, regardless of any other tools in use.
> 
> However, I don't think the way to scale this project is to buckle down and
> try to be a hero-PTL. We need to make the program's mission more appealing
> to a greater number of OpenStack operators that want to deploy and manage
> OpenStack. This will widen our focus, which may slow some things down,
> but we can collaborate, and find common ground on many issues while still
> pushing forward on the fronts that are important to each organization.
> 
> My recent experience with Ansible has convinced me that Ansible is not
> _the_ answer, but that Ansible is _an_ answer which serves the needs
> of some OpenStack users. Heat serves other needs, where Puppet, Chef,
> Salt, and SSH in a for loop serve yet more diverse needs.
> 
> So, with that in mind, I want to succinctly state my priorities for
> the role:
> 
>  * Serve the operators. Our feedback from operators has been extremely
>    mixed. We need to do a better job of turning operators into OpenStack
>    Deployment users and contributors.
> 
>  * Improve diversity. I have been as guilty as anyone else in the past
>    of slamming the door on those who wanted to join our effort but with
>    a different use case. This was a mistake. Looking forward, the door
>    needs to stay open, and be widened. Without that, we won't be able
>    to welcome more operators.
> 
>  * March toward a presence in the "gate". I know that "the gate" is
>    a hot term and up for debate right now. However, there will always
>    be a gate of some kind for the projects in the integrated release,
>    and I'd like to see a more production-like test in that gate. From
>    the beginning, TripleO has been focused on supporting continuous
>    deployment models, so it would make a lot of sense to have TripleO
>    doing integration testing of the integrated release. If there is
>    a continued stripping down of the gate, then TripleO would still
>    certainly be a valuable CI job for the integrated release. We've had
>    TripleO break numerous times because we run with a focus on production
>    ready settings and multiple nodes which exposes new facets of the
>    code that go untouched in the single-node simple-and-fast focused
>    devstack tests.
>    
>    Of course, our CI has not exactly been rock solid, for various
>    reasons. We need to make it a priority to get CI handled for at least
>    the primary tooling, and at the same time welcome and support efforts
>    to make use of our infrastructure for alternative tooling. This isn't
>    something I necessarily think will happen in the next 6 months, but
>    I think one role that a PTL can be asked to serve is as shepherd of
>    long term efforts, and this is definitely one of those.
> 
> So, I thank you for taking the time to read this, and hope that whatever
> happens we can build a better deployment program this cycle.
> 
> -Clint Byrum
> 
> [1] http://lists.openstack.org/pipermail/openstack-dev/2014-August/042589.html
> [2] https://git.openstack.org/cgit/stackforge/tripleo-ansible
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 


-------------- 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/20140924/08c841db/attachment.pgp>