On 18 Nov 2021, at 16:04, Sean Mooney <smooney@redhat.com> wrote:

On Thu, 2021-11-18 at 13:33 +0100, Michał Nasiadka wrote:

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.

i only have reason to use kolla-ansible on small personal clouds at home so either way this will have limited direct affect on me but just wanted to give some toughts:
kolla has been my favorit way to deploy openstack for a very long time, one of the reason i liked it was the fact that it was distro independent, simple ot use/configure and it support source and
binary installs.  i have almost always defautl to ubuntu source although in the rare case si used centos i always used centos binary.

i almost never used binary installs on debian based disto and on rpm based distos never really used soruce, im not sure if im the only one that did that.
its not because i trusted the rpm package more by the way it just seam to be waht was tested more when i cahged to kolla devs on irc so i avoid ubuntu bindary and centos source as a result.

with that in mind debian source is not really contoversial to me, i had one quetion on that however.
will the support for the other distos be kept in the kolla images but not extended or will it be dropped. i asume the plan is to remvoe the templating for other distos in A based on point 3 above.

the only other thing i wanted to point out is that while i have had some succes gettign ubuntu soruce image to run on centos host in the past it will be tricky if kolla every want to supprot
selinx/apparmor. that was the main barrier i faced but there can be other. speficialy ovs and libvirt can be somewhat picky about the kernel on which they run. most of the openstack service will
likely not care that the contaienr os does not match the host but some of the "system" depenciy like libvirt/ovs might. a way to address taht would be to supprot using external images for those servie
form dockerhub/quay e.g. use the offical upstream mariadb image or libvirt or rabbit if that is infact a porblem.

anyway its totally understandable that if you do not have contirbutor that are able to support the other distors that you would remove the supprot.
espicaly with the move away form using kolla image in ooo of late and presumable a reduction in redhat contibutions to keep centos supprot alive. 

anyway the chagne while sad to see just form a proejct health point of vew are sad would not be enough to prevent me personally form using or recommendign kolla and kolla-ansibel.
if you had prorpsed the opistte of centos binary only that would be much more concerning to me. there are some advantages to source installs that you are preservging in this change
that i am glad will not be lost.

one last tought is that if only one disto will be supproted for building images in the future with only soruce installs supproted, it might be worth considering if alpine or the alpine/debian-lite
python 3 iamge  should be revaluated as the base for an even lighter set of contianers rather then the base os image. i am kind fo assumeing that at some poitn the non python noopenstack contaienr
would be used form the offial images at some point rahter then kolla contining to maintain them with the above suggestion. So this may not be applicable now and really would likely be an A or post A
thing.

Best regards,
Michal Nasiadka