James Blair
Monty Taylor
Zuul is a program that drives continuous integration, delivery, and deployment systems with a focus on project gating and interrelated projects.
It is a distributed, massively-scalable, multi-tenant, multi-cloud service designed to be run on the open Internet safely and securely.
To provide software and processes to automate continuous integration, delivery, and deployment of interrelated software projects in a secure manner using project gating.
Zuul is focused on project gating, especially in scenarios involving multiple repositories with integrated deliverables. Zuul tests speculative future states that would result from landing a change rather than merely the change itself. In this it is unique in the industry.
Zuul is a scalable multi-tenant service designed to allow consolidation of administration functions, common shared libraries of content and shared test resources while empowering distributed development teams to operate autonomously.
Zuul content is directly sharable between Zuul installations.
Zuul is flexible and avoids assumptions about how software is written or deployed. Baremetal, VMs, Containers, Network Switches and Kubernetes are all primary targets that can be mixed and matched. Zuul believes CI isn't just for net-new "cloud native" apps, but should be available to everyone.
Zuul is a distributed system consisting of several components.
Zuul is primarily written in Python v3. The web dashboard is in React/Javascript. The zuul-proxy service is in C++.
Zuul depends on Ansible, Zookeeper, Gearman and an RDBMS. (MySQL and PostGreSQL tested)
Zuul has code review drivers for Gerrit and GitHub and node provider drivers for OpenStack, AWS, Kubernetes and Static. Support for more are both underway and welcome.
Zuul publishes tagged releases to PyPI as well as container images from master to Dockerhub.
Zuul was originally written for the OpenStack project and has been running in production at scale since 2012.
Zuul v3 was released Mar 28, 2018.
Since then there have been 13 releases, with the latest, 3.7.1 released Mar 25, 2019.
Zuul is released as needed.
Zuul does not maintain branches of old code. Zuul is designed and expected to be run CD. The Zuul project considers this a feature.
Full governance doc can be found at https://zuul-ci.org/docs/zuul/governance.html.
The Zuul project is self-governing.
Decisions regarding the project are made by the Zuul Maintainers. They are team of people who are familiar with the project as a whole and act as stewards. They are expected to consider the needs of the entire community.
Changes to code, documentation, website and other project resources (including these confirmation slides) are done via code review. In general, approval of 2 maintainers is sought to approve changes, but depending on circumstances a greater or fewer number may be appropriate.
Other decisions are discussed on the mailing list. Maintainers strive to achieve consensus on these topics.
Membership of the Maintainers is decided by consensus of the Maintainers.
Existing maintainers are expected to encourage new members.
There are no artifical limits on the number of Maintainers. A large group of Maintainers is important for the health of the project
Maintainers are encouraged to become involved in all aspects of the project.
The Maintainers elect a Project Lead to articulate overall direction and promote consistency.
The Project Lead does not have any additional rights but does have extra responsibilities.
The Project Lead must pay particular attention to the overall design and direction, ensure everyone is familiar with that design, and facilitate achieving consensus.
If the project is unable to reach consensus on an issue, the Project Lead may conduct a poll of Maintainers. In the case of a tie, the Project Lead's vote will be the tie-breaker.
The Project Lead is elected to a one-year term via Condorcet from a set of self-nominated Maintainers. (The current PL was installed 2019-01-14 by unanimous vote of all 13 Maintainers via code review; no Condorcet poll was required as only one candidate was nominated.)
Documentation is maintained in git with Sphinx and managed via code review.
The Zuul website is also maintained in git and managed via code review.
Zuul uses the OpenDev Gerrit for all code management.
All changes are gated by OpenDev Zuul.
Bugs are tracked in OpenDev Storyboard.
Zuul obeys recognized security and vulnerability management best practices.
Current Zuul Maintainers are employed by Red Hat, BMW, OSF, SUSE and GoodMoney.
All Current Zuul Maintainers have an active role operating a Production Zuul.
Maintainers are expected to consider the entire community, not just their own individual needs.
All Zuul decisions are made collaboratively in community interactions.
Issues found in anyone's Production environment are treated as urgent by all.
Zuul follows the Four Opens.
Additionally, the Zuul community is closely associated with the OpenDev community, which practices Open Operations. Zuul tags releases after verifying operation at scale in OpenDev.
Zuul does not use any proprietary software as part of its development process
The Zuul Community follows the OpenStack Foundation Code of Conduct.
Zuul also behaves as a good neighbor to other confirmed and pilot projects within the OpenStack Foundation.
Zuul is mostly Apache 2. There are some sections of GPLv3 where code is loaded into Ansible processes. The zuul-proxy subproject is GPLv3.
Zuul has been an active participant at all OpenStack Summits and PTGs since before it was split out from the Infrastructure project.
Zuul presentations are given at conferences around the world.
Zuul is being used by OpenLab, the Ansible Community, TungstenFabric and many more.
Since OpenDev runs Zuul, every OpenStack Foundation project using OpenDev is a collaborator.