Open Stack

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?

Thanks!
Tony
________________________________________
Fro: Adrian Andreias <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.


Regards,
Adrian Andreias




On Wed, Dec 1, 2021 at 10:31 PM Tony Liu <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?


Thanks!
Tony
________________________________________
From: Michał Nasiadka <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).

Justification:
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