Octavia-diskimage-retrofit 1.0 track creation

store-requests
1

Hello,

I would like to request a track named 1.0 for the snap named octavia-diskimage-retrofit.

2

Hi!

This snap has no existing tracks, so per Process for aliases, auto-connections and tracks , we need a 1-week voting/discussion period, so I’ll check back on the discussion and votes in a few days. I recognize you requested the track several days ago, so I’ll try to expedite this as to not block you.

I have the usual questions before casting my vote:

  1. What’s the purpose of this snap? :slight_smile:
  2. What’s the release cadence, how often is a new version (potentially requiring a new track) released? is this documented somewhere by upstream? Are you the upstream? :slight_smile:
  3. What’s the intended usage of tracks here? Will you create a new track for each upstream major release?
  4. Is there some commitment from upstream on maintenance of old versions?
  5. Are new versions backwards-incompatible? Meaning, once e.g. 1.1 or 2.0 come out, are people expected to upgrade or are there configuration or data incompatibilities which make an automatic update undesirable?

Thanks!

  • Daniel
3

The Charmed OpenStack product provides a load balancer called Octavia. The Octavia service provides L7 load balancing through the use of virtual machine instances essentially running haproxy. These instances are managed by the service through agents installed in the virtual machine. The upstream Octavia project assumes a image based workflow for getting the agents onto the instances which allows the management network to be isolated and not connected to the internet.

This snap helps in this process and together with the octavia-diskimage-retrofit charm it automates the process of creating the virtual machine images for use with Octavia with Ubuntu Cloud images as input.

Image processing is difficult as it requires access to virtual block devices, and to ensure the charm can be placed on any substrate in a Juju model the libguestfs virt-dib tool is used so that the block device processing happens within a virtual machine. This allows charm placement in LXD containers.

The snap is based on quite stable components (OpenStack Diskimage builder, libguestfs and qemu). These components are used to build the image, the components going into the image come from the Ubuntu archive or the Ubuntu Cloud Archive.

One version of the snap can support many versions of Ubuntu and many versions of OpenStack, so I do not expect a new version requiring a new track to happen very often.

The upstream for the snap is the OpenStack Engineering team in Canonical.

As part of graduating the snap where the target is to host it under the canonical namespace, it has been updated to use classic confinement and a core22 base.

Since this is a substantial change from the previous version the intention is to publish the new stable version in the 1.0 track.

Most of the consumers of the snap use the octavia-diskimage-retrofit charm, so we intend to update the charm to install the snap with the new confinement and target it at the 1.0 track.

This enables us to ensure stability for the user base in where any future breaking changes can be uploaded to a new track.

The artifacts used in the snap come from Ubuntu Jammy and as such we have maintenance included for a good while there. As for the few pieces where the OpenStack Engineering team is the upstream we do intend to maintain them.

There will most likely be minor updates over the next several years to support any smaller changes in the supported distributions and components. The next major refresh of the snap will most likely happen after Ubuntu 26.04 LTS and Core26, and it is hard to tell now what breaking changes may come of that, which is why we want to prepare for that now.

4

Hi,

thanks for the detailed explanation.

“the new stable version in the 1.0 track.” is sort of a red flag - usually one puts old versions in tracks while the latest track maintains the newest, updated version going forward. Just thought I’d mention it in case you need to review your intended use.

That said, we do have snaps that don’t use latest too much and instead point users to tracks for each actively-supported version. So with that precedent and because your explanation makes sense, I’m +1 to granting this track. Let’s poke other @reviewers for an opinion and we’ll create the track once we get more feedback.

  • Daniel
5

+1 to a 1.0 track for octavia-diskimage-retrofit.

6

Thanks, the 1.0 track is now available.

  • Daniel