<div dir="ltr">"source" refers here to OpenStack projects source code:<div><a href="https://opendev.org/openstack/kolla/src/commit/1a9d5a1a42c86b447af371ab5e0864f2b452f6ad/docker/nova/nova-base/Dockerfile.j2#L52">https://opendev.org/openstack/kolla/src/commit/1a9d5a1a42c86b447af371ab5e0864f2b452f6ad/docker/nova/nova-base/Dockerfile.j2#L52</a></div><div><br></div><div>There is no reason to build MariaDB from source. System package are always used (regardless of binary/source config):</div><div><a href="https://opendev.org/openstack/kolla/src/commit/1a9d5a1a42c86b447af371ab5e0864f2b452f6ad/docker/mariadb/mariadb-base/Dockerfile.j2#L14">https://opendev.org/openstack/kolla/src/commit/1a9d5a1a42c86b447af371ab5e0864f2b452f6ad/docker/mariadb/mariadb-base/Dockerfile.j2#L14</a></div><div><a href="https://opendev.org/openstack/kolla/src/commit/1a9d5a1a42c86b447af371ab5e0864f2b452f6ad/docker/mariadb/mariadb-server/Dockerfile.j2#L15">https://opendev.org/openstack/kolla/src/commit/1a9d5a1a42c86b447af371ab5e0864f2b452f6ad/docker/mariadb/mariadb-server/Dockerfile.j2#L15</a></div><div><br></div><div>Image names like "centos-source-mariadb" are probably just kept for consistency.</div><div><br></div><div>If you want to experiment and see what's happening, you can build images yourself:</div><div><a href="https://docs.openstack.org/kolla/latest/admin/image-building.html">https://docs.openstack.org/kolla/latest/admin/image-building.html</a></div><div><br></div><div>Anyhow, the thread is about any blockers on Michał's proposal.</div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"><div>I think it makes sense: less ground to cover and effort will be focused on a few reliable images.</div><div>The only possible issue I can imagine would be a project that already has massive image customizations that are based on binary images.</div><div>Otherwise, minor customizations or standard images should not impact change from binary to source nor to single distro.</div><div><br></div><div><br></div><div>Regards,</div>Adrian Andreias<div><br></div><div><br></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Dec 2, 2021 at 12:04 AM 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">Since I've never used source container and not able to find answers from doc,<br>
bear my dummy questions. BTW, I am not able to figure it out from Dockerfile.j2.<br>
<br>
Take centos-source-mariadb as an example, is it built by 1) installing packages<br>
from package repo or 2) download source code, compile and build packages and<br>
install self-build packages? In case of 2), how can I tell where and which release<br>
source code is downloaded and how it's compiled and built? In case of 1), what's<br>
the difference here from centos-binary-mariadb?<br>
<br>
Similarly, take centos-source-keystone as another example, is it built by<br>
1) installing package from eg. centos/8-stream/cloud/x86_64/openstack-ussuri/<br>
or 2) download source code from Github, build packages locally and install them?<br>
The same questions here, for 1) what's the difference from binary container,<br>
for 2) how can I tell which revision the source code is downloaded?<br>
<br>
Or, the source container is binary container with source code?<br>
<br>
Thanks!<br>
Tony<br>
________________________________________<br>
Fro: Adrian Andreias <<a href="mailto:adrian@fleio.com" target="_blank">adrian@fleio.com</a>><br>
Sent: December 1, 2021 01:30 PM<br>
To: Tony Liu<br>
Cc: Michał Nasiadka; openstack-discuss<br>
Subject: Re: [kolla] Plan to deprecate binary and unify on single distrubition<br>
<br>
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" rel="noreferrer" target="_blank">https://quay.io/search?q=kolla</a><br>
<br>
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>
<br>
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.<br>
<br>
<br>
Regards,<br>
Adrian Andreias<br>
<br>
<br>
<br>
<br>
On Wed, Dec 1, 2021 at 10:31 PM Tony Liu <<a href="mailto:tonyliu0592@hotmail.com" target="_blank">tonyliu0592@hotmail.com</a><mailto:<a href="mailto:tonyliu0592@hotmail.com" target="_blank">tonyliu0592@hotmail.com</a>>> wrote:<br>
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><mailto:<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>