How OpenLab is using Zuul

Zuul is a program that drives continuous integration, delivery and deployment systems with a focus on project gating and interrelated projects. In this series of interviews, we’re talking to users about the problems it’s solving and the challenges they’ve encountered.

Superuser talked to Melvin Hillsman, chair of the OpenStack User Committee who works at Huawei on the open source project OpenLab, about how he’s using Zuul and how you can get involved.

OpenLab is a community-led program to test and improve support for software development kits (SDKs)—as well as platforms like Kubernetes, Terraform, Cloud Foundry and more—in hybrid and multi-cloud OpenStack environments.

How has CI/CD defined new ways to develop and manage software within open infrastructure?

I could be focusing too much on the word “defined” but here are my thoughts. For my sanity, I use the abbreviations CoINT (integration), CoDEL (delivery), and CoDEP (deployment) with CoARC (architecture). I look at these as philosophies that have suggested habits for reduced friction and improved quality of the code developed, released and used as software and/or applications.

Clearly defined new ways of software development and management within open infrastructure can be extracted from the habits they suggest, but these habits are still not exactly common practice. The other issue is that practitioners who implement these habits haven’t established standards about expected outputs or inputs, so it’s difficult to gauge the impact on open infrastructure.

We’re getting there, yet one might argue that open infrastructure is still being defined as well — though we may think we have pinned it down.

To be honest, it’s hard to stick with these habits when you’re starting from nothing and even more so for established small/medium/large companies — even if you’re trying to adhere to them for one software or application in a single business unit.

So tl;dr, we can still use some clear definitions! However, the habits of upstream first, check code in early and often, automate everything, test-driven development, strive for 100 percent test coverage, work in small chunks, test against production-like environments are what folks strive for. It’s evident that confusion is common — there are still articles being written today explaining the differences between CoINT, CoDEL, and CoDEP…

How are you currently using Zuul at OpenLab?

Zuul is currently being used as an offering within OpenLab for projects/applications/tools that need CI gating and/or automation around testing. With the companion tool Nodepool we’re able to keep OpenStack VMs available, speeding up the process for developers of testing code changes.

What benefits have you seen so far?

Primarily the benefit we see is the ease of integration with other projects. Along those lines, Zuul is beneficial in general for open source users who utilize Ansible for other problem domains because it allows for a common language/workflow to be utilized both within the CI/CD system and outside it, opening the door for other tools to be more easily integrated.

What challenges have you overcome?

With Ansible acting as the component Zuul uses to facilitate job definitions it has become easier to onboard. We haven’t yet explored using Ansible Galaxy roles, but we expect to be able to overcome the challenge of having centralized job definitions available outside of the jobs defined within our Github repositories.

What can you tell us about your future plans?

In particular with CI/CD and automating infrastructure/architecture, we’re working with an effort called openci which is about cross-community/foundation/organization integration, deployment, delivery and automation.

Collaboration in this space appears to be still very new as it has been quite varied regarding maturity of tooling, availability of artifacts, common vocabulary and standardized approaches and workflows. With OpenLab, we have the opportunity to explore many aspects of these efforts, helping those who are deploying production environments.

What help could you use from community members (pain points, testing etc.)?

Regarding Zuul – and, as a byproduct in some instances, Nodepool – it would be great to see multi-tenancy land, as well as some additional connection support (Gitlab, Kubernetes Prow, etc.), pushing local repository/code to be included with job run(s) via zuul cli and more robust documentation, to name a few things. We – and others – get great support from the Zuul team via #zuul on freenode. They’re very attentive and extremely knowledgeable — not only about Zuul but also the problem domain it sits in.

Tags: CI/CD, OpenLab, Zuul