Application - PPU OpenStack + Regress-Stack package - Guillaume Boutry

Community Ubuntu Developer Membership
1

Application - OpenStack package set and regress-stack - Guillaume Boutry

I, Guillaume Boutry, apply for upload rights for package set OpenStack and the
regress-stack package.

Contact Information:

I am applying because:

  • I’d like to eliminate delays in getting my work sponsored.
  • I’d like to reduce the burden on my sponsors.

Who I am

I am a software engineer with a focus on OpenStack. I am also a Canonical
employee working in the OpenStack organization. My daily focus is Sunbeam which
is a containerized distribution of OpenStack. All these containers are, for the
most part, built using Ubuntu packages. I dabble in backporting, SRU, and
updating in devel.

My Ubuntu story

I’ve started using Ubuntu 18.04 with Kubernetes containers to ship
applications. My primary focus has been as an application developer using
Ubuntu as a base image.

I’ve actually been using Debian as primary driver for years, but with 20.04, I
have switched to Ubuntu as my primary driver. I got involved in Ubuntu by
working on OpenStack packages primarily.

My first contribution to Ubuntu have been bug reports, specifically to Libvirt:

These two bugs were preventing live migration on recent Intel CPUs. I have
worked with Sergio to get them fixed and backported to 24.04.

Examples of my work / Things I’m proud of

This past cycle, I have bootstrapped the following project: Regress Stack. It’s
a simple OpenStack installer whose goal is to validate regressions in OpenStack
packages. It is small enough to be used in autopackage tests. It is a leaf to
many OpenStack packages, meaning it will help catch regressions moving forward.

The Ubuntu Sponsorship Miner
currently shows 201 sponsored uploads across 136 source packages for my Ubuntu
work. I do not think listing all of them is useful here. The examples below are
the ones I think best show the range of work I have been doing.

Work Examples Why I think it is worth including
OpenStack release work keystone 2:28.0.0-0ubuntu1, nova 3:32.0.0-0ubuntu1, glance 2:31.0.0-0ubuntu1, cinder 2:27.0.0-0ubuntu1 Coordinated OpenStack service uploads for the same release transition, all tied to LP: #2125956.
OpenStack library and dependency syncs python-oslo.cache 3.11.0-0ubuntu1, python-oslo.db 17.3.0-0ubuntu1, python-oslo.service 4.2.2-0ubuntu1, python-keystonemiddleware 10.11.0-0ubuntu1 Shows work beyond leaf packages: keeping the shared Python libraries aligned so OpenStack services can move together, tied to LP: #2116155.
Gazpacho FFE and sync review LP: #2144841, dnspython 2.8.0-1ubuntu1, python-gnocchiclient 7.2.0-2ubuntu1, python-sqlalchemy-utils 0.41.2-3ubuntu2, python-oslo.context 1:6.3.0-2ubuntu1, stevedore 1:5.7.0-2ubuntu1 This is a good example of archive-scale judgment: the FFE reviewed 96 OpenStack-related source packages for sync safety, Ubuntu delta, dependency ordering, component mismatches, CVE risk, and post-sync fixes. The goal is to reduce the Delta between Debian and Ubuntu.
SRU and stable release maintenance horizon 4:24.0.1-0ubuntu0.24.04.1, nova 3:31.0.0-0ubuntu1.1, openstack-pkg-tools 136, glance 2:31.0.0-0ubuntu1.2 Demonstrates that the work is not only development-release uploads; I have also been involved in SRU, and stable maintenance.

Areas of work

I have been involved on the OpenStack packages. I’ve done packaging milestone
and release targets, and caring for the Ubuntu Cloud Archive. Milestones are
specific checkpoints in the OpenStack development cycle, and I firmly believe
Ubuntu should be able to ship these milestones.

While the current situation is not alarming, I do think pro-active maintenance
is needed. We’ve been following the different advancement of the OpenStack
release, and we should focus on closing the gap. Important changes are coming
in the next OpenStack release, such as the eventlet removal, which will require
work at multiple projects. Other projects are going to remove their standalone
daemons in favor of a new service model. This will require some work in the
packaging, and I am looking forward to it.

The thing that was the most challenging to me was the validation model, as
current autopackage tests are not sufficient to validate OpenStack packages
solely from the autopackage tests. While I don’t believe it is currently
possible to actually validate multi-node OpenStack deployments from within the
archive infrastructure, the work I’ve done on Regress Stack are a step in the
right direction as it will allow to run upstream functional tests on the
packages from within the archive infrastructure, actually spawning VMs and
networks from within the archive infrastructure. Regress Stack is also focused
on the core features supported on OpenStack, not all the various features that
are available on OpenStack.

Another area of work that could be improved is the actual contribution to the
OpenStack packages. I would like to reduce the differences between Ubuntu
packages and the OpenStack Ubuntu packages, and have a more gitops-oriented
approach to managing the Ubuntu Cloud Archive, as it is, at the moment, a bit
of a black box. I would like to be able to have a more transparent process for
the Ubuntu Cloud Archive.

As a per-package uploader, I am applying in an area where package maintenance
and bug handling are closely tied to release cadence, archive validation, and
coordination with the Ubuntu OpenStack team. My work has focused on keeping the
OpenStack packages moving through milestones and releases, improving regression
coverage through regress-stack, and handling SRU or backport work where needed.

Things I could do better

My review process could be improved. I tend to focus on the current goal, and
actually nitpicking, while I should improve my feedback to be more constructive
and positive.

Plans for the future

General

As outlined above, I would like to focus on improving the contribution process
for OpenStack packages in Ubuntu, specifically around more robust testing and
validation processes.

What I like least in Ubuntu

I think the main issue is the lack of clarity in the contribution process. It
can be difficult to understand how to contribute effectively, and there are
often barriers to entry for new contributors. Improving documentation and
providing more guidance on the contribution process could help address this
issue.

Endorsements and Comments

Comments

If you’d like to comment, but are not the applicant or a sponsor, add your
comment here.

Endorsements

James’ endorsement copied from: gboutry/OpenStackPackageSetApplication - Ubuntu Wiki

James Page

General feedback
I enjoyed working with Guillaume in Ubuntu - he’s definitely ready for the OpenStack package set and should look to Core Developer status soon - he just needs the opportunities to learn and prove his merit and value to Ubuntu.

Specific Experiences of working together
Guillaume and I worked together on several OpenStack Milestones during the Plucky development cycle; he demonstrated a natural aptitude for the technical aspects of packaging, quickly picking up the core skills required to the point where his proposed uploads only required minimal review/validation.

RegressStack appeared after a discussion about quality of OpenStack in Ubuntu and the need for tests that could be run as part of autopkgtests; Guillaume put together a proof of concept that quickly evolved into a tool that added value to the OpenStack packages, providing much needed in-distro test coverage.

Areas of Improvement
Make sure to take any opportunities to broaden your exposure to more general Ubuntu distro engineering - this will enable you work more quickly towards Ubuntu Core Developer status.

2

Endorsement

  • Purely for sponsoring I had 33 packages working with Guillaume. OpenStack always releases quite close to all freezes and so there often is a rush to update the whole set of them. After many small discussions over a longer time before I did in Spring 2025 help to get this iteration into the Archive (28). Later in August there were 5 more, but those were next cycles upload and not yet the final versions. The model is get git based versions in early and replace them with final version once it exists.
  • The quality of the prepared uploads was good, Guillaume and the OpenStack team have a well established model with repositories from which the changes are pre-reviewed and landed.
  • I found a few small things I wanted to have changed along the sponsoring and found two very great aspects in Guillaume: First of all, he quickly understood all I wanted, no complex explanation or hand holding needed. And second, after bringing it up once he was already storming ahead checking all other uploads and applying the same there which is great.
  • I do trust Guillaume and consider him qualified in regard to requested OpenStack+Regress PPU and would even consider him well informed for python package handling in general.

Areas of improvement and next steps

  • I think this application (and the same for Myles) will help them to cross review and upload these stacks from now on making the OpenStack team independent again. What I expect there is to not become lazy or fast pathing uploads - finding and maintaining their own internal high bar is important as the “pressure → just upload” keeps lingering around every corner.
  • After that I would hope he can here and there pick some cases outside of the OpenStack area every now and then to grow his skill and influence.
  • Finally, too many say in the application in regard what they do not like “lack of clarity in the contribution process”, we are trying but might not see what you see give us PRs please :slight_smile:
3

I endorse Guillaume for PPU.

Sponsoring feedback

I have sponsored many packages for Guillaume over the last few cycles. When we first started working together, I had some suggestions for improving uploads, and Guillaume was quick to take the feedback and incorporate it into future uploads. These days, I have found his work to be very high quality.

Guillaume is very knowledgeable about the OpenStack packages, and combined with his Debian and Ubuntu packaging knowledge, I completely trust him with PPU.

Specific experiences of working together

A good example of Guillaume and I working together is Bug #2144841 “[FFE] Gazpacho Sync of OpenStack packages” : Bugs : openstack package : Ubuntu.

For the last OpenStack release, many manual syncs were required from Debian to get the Ubuntu packaging to follow Debian again where it had previously gone ahead. Some packages required merges or other special considerations. Guillaume carefully did the analysis and provided me the confidence to sponsor the large number of syncs.

An example of a merge that was required is 3.4.5-1ubuntu1 : python-ldap package : Ubuntu, which was handled very well.

Areas of improvement and next steps

Although Guillaume works mostly on a specific set of packages, it is a large set and he has developed good general packaging skills. He could strive for further upload rights later, and participate in +1 maintenance rotations to give more experience.