<div dir="ltr">The user doesn't have to build the images that are source based. Ready built source-based images are available: <a href="https://quay.io/search?q=kolla">https://quay.io/search?q=kolla</a><div><br></div><div>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.<br><div><br></div><div>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.</div><div><br></div><div><div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"><div><br></div><div>Regards,</div>Adrian Andreias<div><br></div><div><br></div></div></div></div></div><br></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 1, 2021 at 10:31 PM Tony Liu <<a href="mailto:tonyliu0592@hotmail.com">tonyliu0592@hotmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">For OpenStack, I've been using centos-binary containers on CentOS. It's been working very well.<br>
<br>
I don't have much concern on supporting single-distro based container on different distro hosts.<br>
That's actually one of the beauties of container, which self-contains all packages and dependencies.<br>
We used to have a product based on single-distro container and support different distro hosts.<br>
Just need to be careful when container needs any resource from the host, like kernel, mounted<br>
host filesystem, networking, privilege, etc.<br>
<br>
Regarding to source container, what's the purpose of it? Is it allow user to get the package based<br>
on some specific source that is not provided by any existing package repo? In that case, I'd assume<br>
user should always build their own source container. Then what's the purpose of providing pre-build<br>
source container? Also, are those non-core containers, like MariaDB, HAProxy, RabbitMQ, etc. all<br>
built from source code?<br>
<br>
<br>
Thanks!<br>
Tony <br>
________________________________________<br>
From: Michał Nasiadka <<a href="mailto:mnasiadka@gmail.com" target="_blank">mnasiadka@gmail.com</a>><br>
Sent: November 18, 2021 04:33 AM<br>
To: openstack-discuss<br>
Subject: [kolla] Plan to deprecate binary and unify on single distrubition<br>
<br>
Hello Koalas,<br>
<br>
On the PTG we have discussed two topics:<br>
<br>
1) Deprecate and drop binary type of Kolla images<br>
2) Use a common base (single Linux distribution) for Kolla images<br>
<br>
This is a call for feedback - for people that have not been attending the PTG.<br>
<br>
What this essentially mean for consumers:<br>
<br>
1) In Yoga cycle we will deprecate binary type of Kolla images, and in Z cycle those will be dropped.<br>
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.<br>
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).<br>
<br>
Justification:<br>
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.<br>
By dropping binary type of images - users would be running more tested images (since Kolla/Kolla-Ansible CI runs source images jobs as voting).<br>
In Xena we’ve already changed the default image type Kolla-Ansible uses to source.<br>
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<br>
<br>
Request for feedback:<br>
If any of those changes is a no go from your perspective - we’d like to hear your opinions.<br>
<br>
Best regards,<br>
Michal Nasiadka<br>
<br>
</blockquote></div>