Open Stack

"source" refers here to OpenStack projects source code:
https://opendev.org/openstack/kolla/src/commit/1a9d5a1a42c86b447af371ab5e0864f2b452f6ad/docker/nova/nova-base/Dockerfile.j2#L52

There is no reason to build MariaDB from source. System package are always
used (regardless of binary/source config):
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-server/Dockerfile.j2#L15

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:
https://docs.openstack.org/kolla/latest/admin/image-building.html

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.


Regards,
Adrian Andreias



On Thu, Dec 2, 2021 at 12:04 AM Tony Liu <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?
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20211202/51087e85/attachment-0001.htm>