[OpenStack Foundation] OpenStack TC feedback on Zuul for OIP Confirmation

Mohammed Naser mnaser at vexxhost.com
Thu Apr 4 20:03:02 UTC 2019

Per the OSF Project Confirmation Guidelines[0], the OSF Board of
directors is soliciting feedback from representatives of existing
confirmed Open Infrastructure Projects (so far that's just OpenStack)
when evaluating the Zuul pilot project's upcoming application for OIP
confirmation. We reached out to the OpenStack community to get an idea
of what interactions have been experienced or observed relevant to
these guidelines, and compiled them in an Etherpad[1] for ease of
collaboration. The feedback is broken down by each of the five major
guideline headings along with a catch-all at the end. Here follows an
attempt to summarize what we've learned:

Zuul furthers the strategic focus of the OSF, helping open
infrastrucure projects ensure the highest possible levels of code
quality by applying the concept of project gating. It is responsible
in great part for the success of OpenStack and OpenDev, as well as
found useful by other pilot projects like Airship and StarlingX. It's
widely seen as a simplifying force for our continuous integration and
project infrastructure. Zuul itself makes heavy use of OpenStack-based
services and considers those a first-class supported feature.

The governance[2] for Zuul is fairly straightforward, perhaps
described in OpenStack terms as a team of consensus-seeking core
reviewers (the Zuul Maintainers) who elect a PTL (the Zuul Project
Lead) from within their ranks rather than relying on anyone who has
contributed a patch to do so. It is also somewhat analogous to how the
OpenStack TC elects its chair, though the Zuul Maintainers are a
self-selected group rather than being elected by other patch
submitters. Given that in OpenStack each PTL is basically always
already a core reviewer and a consensus choice of their peers (and
almost always the only candidate nominated), and that PTLs tend to
defer addition and removal of new core reviewers to consensus among
the existing cores, this seems like a model based in the reality of
team dynamics.

The Zuul project has not discarded the recommended practices from its
origins as a part of OpenStack, and indeed is itself responsible for
instating many of those practices within OpenStack. The OpenStack
community is particularly fond of Zuul's extensive, integrated
documentation[3] on which it heavily relies. While there are
instructions[4] on how to report suspected vulnerabilities and the
team is regularly publishing advisories[5][6][7], it was noted that
there is not yet a published document describing the vulnerability
management process followed so this is a potential area for

Similarly, Zuul's fundamental collaboration model is also inherited
from its OpenStack roots (or you could say Zuul was responsible for
much of it while still a part of OpenStack). The members of the Zuul
community are happy to help users, including other Open Infrastrucure
Projects and OSF pilot projects, solve their problems even (or perhaps
especially) when it means Zuul itself needs to grow new features to do
so. There was one note that it might be nice to get a clearer picture
as to how Zuul relates or could relate to the projects in the
newly-formed CD Foundation[8].

As to active engagement, Zuul is remarked as having an obvious
diversity of developers and production users from many companies with
a rapidly growing ecosystem and presence at industry events like
AnsibleFest. The Zuul community has also been observed going to great
lengths in assisting new deployers of its software, many of whom are
notably operators of third-party CI for testing drivers and features
of various OpenStack subsystems. Even the software itself is
considered to be a tool of outreach, leaving its own inline review
comments for syntax errors in proposed configuration changes.

[0] https://wiki.openstack.org/wiki/Governance/Foundation/OSFProjectConfirmationGuidelines
[1] https://etherpad.openstack.org/p/openstack-tc-zuul-confirmation-feedback
[2] https://zuul-ci.org/docs/zuul/governance.html
[3] https://zuul-ci.org/docs/
[4] https://zuul-ci.org/docs/zuul/user/vulnerabilities.html
[5] http://lists.zuul-ci.org/pipermail/zuul-announce/2018-November/000027.html
[6] http://lists.zuul-ci.org/pipermail/zuul-announce/2019-January/000032.html
[7] http://lists.zuul-ci.org/pipermail/zuul-announce/2019-March/000035.html
[8] https://cd.foundation/

Mohammed Naser — vexxhost
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mnaser at vexxhost.com
W. http://vexxhost.com

More information about the Foundation mailing list