Open Stack

Hi Thomas,

Thanks for your opinion - but we can’t really wait until each Debian OpenStack release to test all the features (and what will be broken) - we already trail long time after the official OpenStack release due to other issues.
That would significantly lengthen the delay and the process involved.

Kolla has been doing voting CI on source images for a long time - and we don’t want to change it.

It’s also a direction to make the external dependencies smaller - not bigger - and I see the custom things added from packager perspective as a dependency.

Best regards,
Michal

> On 2 Dec 2021, at 01:04, Thomas Goirand <zigo at debian.org> wrote:
> 
> 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...
>