Hi ! I thought my perspective might be valuable as the author of a project that would likely end up being slashed: ARA [1].
In a nutshell, ARA provides easy and seamless Ansible reporting on playbook runs. It has nothing to do with OpenStack, to be honest: it doesn't require OpenStack to run, it doesn't run on OpenStack. We highlight that ARA is not an "official" OpenStack project in the contributors' documentation [2]. But, it was born out of necessity inside the RDO community (call that the extended OpenStack community, if you will) due to the vast amount of our workloads that are driven by Ansible. I like to draw a parallel between ARA and JJB [3] (Jenkins Job Builder) as two tools that the OpenStack community develops and use without slapping the OpenStack brand on them. If we take a step back, would projects like Nodepool or Zuul also be affected by this kind of cut ? Where do we draw the line ? Are they OpenStack projects or not ? For me, applying for ARA to be hosted as a "community" project [4], or what would've been a "Stackforge" project long ago, was a completely logical choice to me. I could go and praise how the Gerrit workflow is vastly superior than GitHub pull requests or that the Zuul-driven CI is completely awesome. But... The truth is that I sincerely hoped it would help the project gain exposure and credibility in order to drive adoption *inside* the OpenStack community. We say that hindsight is 20/20, but, in retrospect [5], I guess we could say it worked. Maybe out of luck, maybe out of sheer dedication and long weekends spent working on the project. The reality is that today, ARA is used by many different projects inside the OpenStack ecosystem -- to name a few: - OpenStack-Ansible - TripleO - Browbeat - Kolla/Kolla-Ansible - Devstack-Gate But also, like Jenkins Job Builder, it has gained adoption outside of the OpenStack community -- such as inside the OpenShift Ansible community or BonnyCI. Being part of the OpenStack "ecosystem" allows ARA to do things like easily implement a gate job almost verbatim from OpenStack-Ansible [6] to make sure that each new commit doesn't break them. I feel that this is useful and powerful not just for ARA but for OpenStack-Ansible and the other projects that use it as well. Ironically, some projects feel hindered by this ecosystem (see: Gnocchi) and have made an exit. I do not share these feelings and I would in fact be very sad to be shown the door. My 0.02$CAD (not worth much right now) [1]: https://github.com/openstack/ara [2]: http://ara.readthedocs.io/en/latest/contributing.html#contributing [3]: https://github.com/openstack-infra/jenkins-job-builder [4]: https://review.openstack.org/#/c/321226/ [5]: https://dmsimard.com/2017/05/08/ara-is-one-year-old-a-look-back-at-the-past-year/ [6]: https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/ara.yaml#L21-L89 David Moreau Simard Senior Software Engineer | Openstack RDO dmsimard = [irc, github, twitter] On Jun 28, 2017 6:46 PM, "James E. Blair" <cor...@inaugust.com> wrote: Thierry Carrez <thie...@openstack.org> writes: > Removing the root cause would be a more radical move: stop offering > hosting to non-OpenStack projects on OpenStack infrastructure > altogether. We originally did that for a reason, though. The benefits of > offering that service are: > > 1- it lets us set up code repositories and testing infrastructure before > a project applies to be an official OpenStack project. > > 2- it lets us host things that are not openstack but which we work on > (like abandoned Python libraries or GPL-licensed things) in a familiar > environment > > 3- it spreads "the openstack way" (Gerrit, Zuul) beyond openstack itself I think this omits what I consider the underlying reason for why we did it: It helps us build a community around OpenStack. Early on we had so many people telling us that we needed to support "ecosystem" projects better. That was the word they used at the time. Many of us said "hey, you're free to use github" and they told us that wasn't enough. We eventually got the message and invited them in, and it surpassed our expectations and I think surprised even the most optimistic of us. We ended up in a place where anyone with an OpenStack related idea can try it out and collaborate frictionlessly with everyone else in the OpenStack community on it, and in doing so, become recognized in the community for that. The ability for someone to build something on top of OpenStack as part of the OpenStack community has been empowering. I confess to being a skeptic and a convert. I wasn't thrilled about the unbounded additional responsibility when we started this, but now that we're here, I think it's one of the best things about the project and I would hate to cleave our community by ending it. -Jim __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
