[kolla] Plan to deprecate binary and unify on single distrubition

Tony Liu tonyliu0592 at hotmail.com
Wed Dec 1 23:14:55 UTC 2021

Thank you Adrian for clarifications!
I am good with Michał's proposal, although it will add a bit overhead to
rpm-operator when need to look into container. For example, you need
to keep it in mind that the container is Debian based and run dpkg instead
of rpm.

From: Adrian Andreias <adrian at fleio.com>
Sent: December 1, 2021 03:04 PM
To: Tony Liu
Cc: Michał Nasiadka; openstack-discuss
Subject: Re: [kolla] Plan to deprecate binary and unify on single distrubition

"source" refers here to OpenStack projects source code:

There is no reason to build MariaDB from source. System package are always used (regardless of binary/source config):

Image names like "centos-source-mariadb" are probably just kept for consistency.

If you want to experiment and see what's happening, you can build images yourself:

Anyhow, the thread is about any blockers on Michał's proposal.
I think it makes sense: less ground to cover and effort will be focused on a few reliable images.
The only possible issue I can imagine would be a project that already has massive image customizations that are based on binary images.
Otherwise, minor customizations or standard images should not impact change from binary to source nor to single distro.

Adrian Andreias

On Thu, Dec 2, 2021 at 12:04 AM Tony Liu <tonyliu0592 at hotmail.com<mailto:tonyliu0592 at hotmail.com>> wrote:
Since I've never used source container and not able to find answers from doc,
bear my dummy questions. BTW, I am not able to figure it out from Dockerfile.j2.

Take centos-source-mariadb as an example, is it built by 1) installing packages
from package repo or 2) download source code, compile and build packages and
install self-build packages? In case of 2), how can I tell where and which release
source code is downloaded and how it's compiled and built? In case of 1), what's
the difference here from centos-binary-mariadb?

Similarly, take centos-source-keystone as another example, is it built by
1) installing package from eg. centos/8-stream/cloud/x86_64/openstack-ussuri/
or 2) download source code from Github, build packages locally and install them?
The same questions here, for 1) what's the difference from binary container,
for 2) how can I tell which revision the source code is downloaded?

Or, the source container is binary container with source code?

Fro: Adrian Andreias <adrian at fleio.com<mailto:adrian at fleio.com>>
Sent: December 1, 2021 01:30 PM
To: Tony Liu
Cc: Michał Nasiadka; openstack-discuss
Subject: Re: [kolla] Plan to deprecate binary and unify on single distrubition

The user doesn't have to build the images that are source based. Ready built source-based images are available: https://quay.io/search?q=kolla

Binary-based Kolla docker images are installing (at image build time) OpenStack projects via system packages, while source based images are symply adding projects' Python source code.

Just as you said, the user shouldn't care much about distro inside images. But makes things a lot easier for developers to maintain less images and without working around different versions and dependencies provided by the system packages of various distros.

Adrian Andreias

On Wed, Dec 1, 2021 at 10:31 PM Tony Liu <tonyliu0592 at hotmail.com<mailto:tonyliu0592 at hotmail.com><mailto:tonyliu0592 at hotmail.com<mailto:tonyliu0592 at hotmail.com>>> wrote:
For OpenStack, I've been using centos-binary containers on CentOS. It's been working very well.

I don't have much concern on supporting single-distro based container on different distro hosts.
That's actually one of the beauties of container, which self-contains all packages and dependencies.
We used to have a product based on single-distro container and support different distro hosts.
Just need to be careful when container needs any resource from the host, like kernel, mounted
host filesystem, networking, privilege, etc.

Regarding to source container, what's the purpose of it? Is it allow user to get the package based
on some specific source that is not provided by any existing package repo? In that case, I'd assume
user should always build their own source container. Then what's the purpose of providing pre-build
source container? Also, are those non-core containers, like MariaDB, HAProxy, RabbitMQ, etc. all
built from source code?

From: Michał Nasiadka <mnasiadka at gmail.com<mailto:mnasiadka at gmail.com><mailto:mnasiadka at gmail.com<mailto:mnasiadka at gmail.com>>>
Sent: November 18, 2021 04:33 AM
To: openstack-discuss
Subject: [kolla] Plan to deprecate binary and unify on single distrubition

Hello Koalas,

On the PTG we have discussed two topics:

1) Deprecate and drop binary type of Kolla images
2) Use a common base (single Linux distribution) for Kolla images

This is a call for feedback - for people that have not been attending the PTG.

What this essentially mean for consumers:

1) In Yoga cycle we will deprecate binary type of Kolla images, and in Z cycle those will be dropped.
2) We are not going to support CentOS Stream 9 (cs9) as a base operating system, and the source type build will rely on CentOS Stream 8 in Z release.
3) Beginning from A release Kolla will build only Debian source images - but Kolla-Ansible will still support deployment of those images on CentOS/Ubuntu/Debian Host operating systems (and Rocky Linux to be added in Yoga to that mix).

The Kolla project team is limited in numbers, therefore supporting current broad mix of operating systems (especially with CentOS Stream 9 ,,on the way’’) is a significant maintenance burden.
By dropping binary type of images - users would be running more tested images (since Kolla/Kolla-Ansible CI runs source images jobs as voting).
In Xena we’ve already changed the default image type Kolla-Ansible uses to source.
We also feel that using a unified base OS for Kolla container images is a way to remove some of the maintenance burden (including CI cycles and

Request for feedback:
If any of those changes is a no go from your perspective - we’d like to hear your opinions.

Best regards,
Michal Nasiadka

More information about the openstack-discuss mailing list