Open Stack

On 11/18/21 1:33 PM, 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.
> 
> Best regards,
> Michal Nasiadka

Hi,

While I fully support moving to a Debian only world (anyone who knows me
isn't surprised to read this...), I really wonder if moving to a "source
only" world is the right step.

If you don't have enough people, why don't you just move to a Debian
package only type of install, rather than re-implementing all by
yourself? The very point of packages is to abstract for you many things,
like for example, the fact that Nova has a reserved UID/GID of 64060 in
Debian, and will always use that one, and automatically set that up for
you, plus put the Nova user in the right group... Or if you need another
example, making sure that swift-proxy starts with the right "route = .*
addheader:Date: ${httptime[]}" uwsgi parameter... etc.

Now, if you have a limited amount of contributors, all these tiny tweaks
that the package maintainers are doing for you, you'll have to
re-implement them yourself. Worse: it's going to be even more
complicated if you put stuff in containers.

Using source only images, you also don't get all the testing that's done
by distro on funny arch which you probably didn't think of. Yes, the
openvswitch package in Debian is tested and working on the 10 official
Debian arch. The lz4tools contains a 32 bits patch. Or is it that you
don't care about anything else than x86_64?

So why don't you just take the other direction, and drop the source
images? I'm sure this will save you a lot of work. Plus myself and
Michal will make sure everything works, and is available in time for
every release, like we always did (did you notice Debian is often (if
not always) the first distro to have available packages for each release?).

Cheers,

Thomas Goirand (zigo)

P.S: I'm using puppet-openstack myself, so I wont ever contribute to
Kolla and/or OSA, but I still would like to support you...