Zuul case study: Software Factory

Zuul drives continuous integration, delivery and deployment systems with a focus on project gating and interrelated projects. In a series of interviews, Superuser asks users about why they chose it and how they’re using it.

Here Superuser talks to the Software Factory team: David Moreau Simard, Fabien Boucher, Nicolas Hicher, Matthieu Huin and Tristan Cacqueray.

SF is a collection of services that provides a powerful platform to build software. Designed to be deployed in anyone’s infrastructure, the project started four-and-a-half years ago and is vastly influenced by the OpenStack project infrastructure. The team operates an instance at https://softwarefactory-project.io where the project is being developed. RDO’s CI at https://review.rdoproject.org is also based on an SF deployment.

In one of the blog posts it’s explained that “SF is for Zuul what Openshift is for Kubernetes,” what are the advantages for users with Software Factory?

SF is a distribution that integrates all the components as CentOS packages with an installer/operator named sfconfig to manage service configuration, backup, recovery and upgrades. The main advantage for our users is the simplicity of use. There’s a single configuration file to customize the settings and all the services are configured with working defaults so that it is usable out of the box. For example, Zuul is setup with default pipelines and the base job automatically publishes jobs artifacts to a log server.

Another advantage is how customizable deployments can be: whether you need a whole software development pipeline from scratch, from a code review system to collaborative pads, or if you just want to deploy a minimal Zuul gating system running on containers, or if you need an OpenStack third party CI quickly up and running, SF has got you covered.

SF also sets up CI/CD jobs for the configuration repository, similar to the openstack-infra/project-config repository. For example, SF enables users to submit project creation requests through code review and a config-update post job automatically applies the new configuration when approved.

To learn more, check out this presentation: http://www.softwarefactory-project.io/how-to-setup-a-software-factory-sandbox.html and the project documentation: https://softwarefactory-project.io/docs .

How are people are using SF?

The RDO project has been using SF successfully for about three years now. The goal is to keep the same user experience from upstream to downstream and to allow them to share configurations, jobs, pipelines and easily run third party CI jobs.

With the addition of GitHub support to Zuul, SF can now be used without Gerrit and people are looking into running their own gating CI/CD for GitHub organizations with SF to use the log processing features.

As mentioned earlier, we dogfood the platform since we do our CI on SF, but we also have a release pipeline for the developers team’s blog: the CI pre-renders the tentative articles and once they’re approved they are automatically published.

The latest Software Factory release adds support for tenant deployment and Zuul configuration management from the resources. What does this mean for users and why is it important to ship now?

While Zuul supports multi-tenancy, the rest of the services such as Gerrit or log processors do not. The latest SF release enables tenants to deploy these services on a dedicated and isolated instance. This is important for us because we can now consolidate the RDO deployment to share the same Zuul instance used by softwarefactory-project.io, so that we can rationalize the use of our shared resources.

We are also onboarding the Ansible network organization at https://ansible-network.softwarefactory-project.io to leverage OpenStack cloud provider for network appliance testing.

There are a lot of features for possible Zuul future contributions, which are highest priority?

The highest priority is to provide a seamless experience for Jenkins users. Similar to the OpenStack project infrastructure, SF used to rely on Jenkins for job execution. To improve the user experience, we contributed some features such as jobs and builds web interface in Zuul. However, we still lack the capacity to abort and manually trigger jobs through the REST API and we’d like to see that sooner rather than later.

Another goal is to be able to run jobs on OpenShift and we would like to see Nodepool be able to do that too.

Generally speaking, a modular, plugin-based architecture would allow third parties like us to experiment with Zuul without burdening the community with contributions that might be of lower priority to them.

The days of annual, monthly or even weekly releases are long gone. How is CI/CD defining new ways to develop and manage software within open infrastructure?

As hinted above, we have a more nuanced opinion regarding continuous deployment: it’s great for some workflows but overkill for some others, so it really depends on your production environment and needs. We are, however, firm believers in continuous integration in general and code gating in particular and we hope to see more development teams adopting the “OpenStack way” of doing CI, possibly after trying out SF!

Continuous delivery is a big challenge for packaging RPMs, especially when following an upstream source and especially when this upstream source is OpenStack where hundreds of changes get merged every day. The RDO community came up with a “master chaser” called DLRN which, combined with Software Factory, allows them to ensure that OpenStack packages are always healthy, or at least notify packagers as fast as possible when a change introduces a problem. This new way of managing software is what allows RDO to deliver working OpenStack packages for CentOS just mere hours after an upstream release.

Generally speaking, CI/CD becomes incredibly powerful when paired with the concept of everything as code. Virtualization, containerization, provisioning technologies turn whole infrastructures into code repositories on which you can apply CI and CD just like you would on “ordinary” code. We actually toyed a while ago with a proof-of-concept where SF would be used to test and deploy configuration changes on an OpenStack infrastructure with OSP Director. Imagination is the limit!

Got questions? You’ll find the Zuul team at AnsibleFest Oct. 2-3. You can also check out the sessions featuring Zuul at the upcoming Berlin Summit.

Photo // CC BY NC

Tags: CI/CD, Software Factory, Zuul