Using ubi7 images instead on centos7 for future manylinux images

I wanted to share the GA of ubi7 container images which are similar to rhel7 images.They are free to distribute.More details here
Can the community adopt ubi7 images ?

It’s going to be a bit before we have any centos7/rhel7 images (it’s in progress, but we have several other steps to get through first). So this is mostly only of theoretical interest right now.

What’s the advantage of ubi images over centos images? That post you linked to is clear about the advantage over rhel images (you can actually distribute them publically!), but that’s not really relevant to us…

This is an effort to start a conversation about this new image; which is like rhel and has the same rpms as in rhel. In container world we previously used centos7 containers because we didn’t want to use rhel since it needed subscription $$ but now we don;t need subscription.
So we have the latest and greatest rpms, gcc and also devtoolset from RH free of cost.

Also, ubi8 image is available and cento8 container image is not released yet.
ubi7 image supports architectures( supported by centos7 and works with the oldest system out there.

AFAIK the only difference between RHEL’s rpms and CentOS’s rpms are (a) marketing, (b) the option to buy a support contract, which we don’t care about. They’re both maintained by RH, they both have the same rpms, devtoolset, etc.

That makes it easy to decide on ubi7. ubi7 rpms don’t have marketing and they come free for community and everyone.You can buy the support contract but I would be the first to point out that it is not required.
There is no parity of releases between with centos7 and rhel7.

My understanding was that centos was selected because (Anaconda chose it and seemed to be doing okay) it hit the right balance of “libraries that typical distros have available”, and so building against them gives binaries the best chance of working on many Linux machines.

Does ubi also fit this criteria?

It’s more that RHEL/CentOS are the oldest systems that people actually use, so making wheels compatible with them is similar to making wheels that work on old Windows or old macOS.

IIUC, ubi is rhel, which has exactly the same ABI as centos version X. So they’re totally equivalent in that regard. I’m still really not clear on why @sub-mod thinks ubi has an advantage. Does ubi get free access to the full RHEL package repos?

We should probably ask some RH folks, like @tiran or @encukou.

1 Like

@njs FYI, Subin works at Red Hat as well.

Huh, so a RH employee, using a semi-anonymous handle, is promoting a RH product, using vague terms and claiming it has “no marketing”? @sub-mod, I’m sure you’re just enthusiastic and no harm was meant, but you gotta be more careful about this kind of thing, it can really leave a bad taste in people’s mouths.

I would still really appreciate if someone could post a clear description of the technical differences between the ubi and centos images, like any differences in ABI, support, and package availability.

Disclaimer 1: I’m a Red Hat employee.
Disclaimer 2: I am not a lawyer.

Universal Base Images are official RHEL container images. The wheel use case may fall under the free, no-cost RHEL developer license. Both UBI and RHEL dev license are fairly new and were introduced in the past two years. The wheel standard pre-dates them.

It might be possible to use a combination of UBI and free developer license to create official wheel builder containers. RHEL images may have some benefits, e.g. they are usually available earlier than CentOS and are officially supported by Red Hat. I can raise the issue with our legal department for official legal advise and UBI engineering department for technical advise.

lol there is “no-marketing”.I don’t get paid if someone uses ubi images.
" semi-anonymous handle" comment was unnecessary since I use the same nick(sub-mod) for github and twitter(

jfyi …UBI images have UBI#EULA which is different from RHEL#EULA and allow redistribution.

In Python-dev we have an unwritten rule for anything that may look remotely like an advertisement. We pro-actively communicate any involvement and financial ties to companies in order to avoid any pretense. Neither Nathaniel nor I knew that you are a co-worker of mine.

I’m aware of the difference. For wheels we’d need more than just the bare UBI image. I don’t know how much is covered by the EULA and I like to do things by the book. Plus I know that engineering teams love to get feedback and see how their products are used by customers.

I am the product manager, at Red Hat, for UBI (and container tools like podman, and CRI-O). I am happy to answer any questions. I am also a long time Python programmer, so I have a soft spot there.

I’m sure Subin didn’t mean any harm, and is just excited about UBI, but I totally understand why you might be nervous.

Couple of things I read in this thread, and a few things in my mind:

  1. CentOS is not the same as RHEL. It’s compiled by a completely different team, with a completely different set of build tools, on a different build system, with different tracking systems, etc, etc
  2. CentOS is not guaranteed to be ABI compatible. The code is identical, but the binaries are not. Though, binaries often “just work” they are not guaranteed to perform at the same level, not be free of CVEs.
  3. CentOS can have all kinds of things different, like boot options, compile time options, etc
  4. CentOS comes out after RHEL, so during the RHEL 8 beta and UBI Dev Preview (many months long), there was no CentOS 8. UBI partners using the Dev Preview had access.
  5. With the release of RHEL 8, RHEL is going to move much faster. Six week Z stream releases for bug fixes, quarterly releases for Appstreams, 6 month minor releases (8.1, 8.2, 8.3, etc) and the next major release is planned for 3 years. This is a huge break from the past (aka RHEL7) and will make UBI more valuable and likely much faster than CentOS.
  6. UBI is RHEL. Same build system, compile options, same lifecycle, etc. UBI provides beta images for major releases. For example, when RHEL9 comes out, UBI users will have access months earlier than CentOS.
  7. CentOS is a superset of RHEL. Some packages get added which are not in RHEL, especially in the different focus areas.
  8. UBI is a subset of RHEL (focused on things like Python). So, if you find a package that’s not there and, you need it, we will try to get it added.
  9. Python is a targeted use case for UBI. We want to satisfy Python dependencies in UBI. We had to limit UBI a bit, because there is concern that it could eat into RHEL, but we are adding as much content as possible. We will never remove packages from UBI (people have asked, so I have to state it).
  10. UBI is guaranteed to have the same 10 year lifecycle as RHEL. We will produce images for many more years in UBI7, and 10+ years in UBI 8.
  11. UBI has a predictable rebuild policy. Every 6 weeks and everytime a critical CVE is found. Also, the UBI YUM repo updates on the same RHEL, six week policy. These are way more predictable than CentOS.
  12. UBI has a “potential” path to support. Different people will care about this at different levels, but CentOS has no path to Red Hat support even if an end users wants it. UBI gives end users the choice (people who consume the built layered images)

I can’t think of anything else to add (and I need to capture this as a blog entry), but I do have a question. What is the “wheel” use case mentioned here? I am not familiar with this? Perhaps it’s something I can make sure we target with UBI.

I’m not lawyer either, but was intimidately involved in the creation of the EULA and can probably answer almost anything. With UBI, we, Red Hat want to give the world something better than CentOS for containers. That’s basically one of my charters.

with my Python hat on, and a disclaimer that I do work for Red Hat:

Wheels are a binary distribution format for Python packages. Like RPMs, but installable in virtual environments (i.e. not strictly system-wide).
Currently, Linux wheels are called manylinux and are built on CentOS 5, the oldest distro used today, with components that have strong forward-compatibility policies (like gcc, x11, curses). Any other native libraries are vendored into the wheel. This makes manylinux wheels likely to work with many other Linux distros.
We don’t need extra packages in the image.
We also don’t care about compatiblity with RHEL (any more than with all other distros).
We don’t really mind month-long delays.
Individual maintainers build manylinux wheels on their own, using a common Docker image. CentOS, being completely free to redistribute, allows that legally.


What Petr said :slight_smile:

Scott, you can find more information and a definition of the manlinux1 and manylinux2010 wheel standards at

1 Like