On Tue, 2024-08-13 at 00:56 +0800, 韩光宇 wrote:

Hello,

As an OpenStack operator who is also involved in packaging OpenStack, I've recently encountered some confusion regarding the packaging of OpenStack. From what I've gathered, Red Hat, SUSE, and Ubuntu package OpenStack in such a way that a single OS version can support multiple OpenStack versions. Each OpenStack version corresponds to its own separate repository (please correct me if I'm mistaken).

that works slightly differntly on each disto. ubuntu package the latest release in each non lts verison of ubuntu and there lts release supprot each subsequent openstack until the next lts. so 22.04 will have the openstack from 22.10 23.04 23.10 and 24.04 there upgrade model is you upgrade openstack first to the version shared with the next lts then you upgrade the OS to match. beause of there 6 month release cycle they have one opentack relase per release. Red hat does things slightly diffently. we only ship specific upstream version downstream and we skip all release inbetween in 16.0 we intoduced the concept of mixed rhel mode which allowed you do take the same upgade appoch as canoninca with respect to updating the openstack version first then upgrading rhel. so 16.2 (train) on rhel 8.4 -> 17.1 (wallaby) on rhle 8.4 then 17.1 on 8.4 is upgraded to 17.1 on 9.2 to alligh with our greenfild support. any feature that depend on the new rhel release are unsupproted in the mixed rhel state until you finish the upgrade. that is largely things that deplend on the new kernel version or new libvirt/qemu version. redhats product is contaienr based and while repos do exist with rpms no supprot is provided for installing the rpm direcly on a rhel host. only the containers are supproted offically in our product. form a comunity perspective its slightly differnt. RDO which is one of the two souces of comuntiy built rpms provdie rpms for each updatrema release and uses centos stream for testign but they shoudl instlal on rocky as well they might work on suse too but i dont know if that is supproted. SUSE discontinued there openstack product a few years ago so i dont think the downstream SUSE supprot openstack but i would expect the RDO rpms to work on tumbleweed if the depencies aline. there is also an upstream rpm pakcage efffort sepertate form rdo that also provided repos and rpms for each release.

I'm trying to understand the implications this packaging approach might have on system compatibility and maintenance. Such as, could this lead to the following scenario:

The system repository has package A==1.0, The OpenStack repository has package A==2.0. After installing A==2.0 from the OpenStack repository, package B (which depends on A<=1.0) from the system repository can no longer be installed.

Does this mean that the OpenStack repository breaks overall compatibility?

if the openstack repo shipt incompatible deps it could in the rpm world eple is not ment to ship any content in base rhel/centos for rdo they also try to follwo that rule and cordiate the version vai the cloud sig. ubuntu via the cloud arcives also ship the openstack release fro the prior LTS when point releases happen but cananonical ensure that this kind fo breakage wont happen. so unless your disto is packaing openstack incorrecly the openstack repo should use the distos version of packages like mysql and should not have conflict. i know that debian and perhaps other distos have a policy where they dont want to have 2 version fo the same package. this has caused issues with compatiblity in debian in the past were the two are not aligned but even then i think the breakage you are discibing wont happen if your using the offical debian repos for a release. the opendev foundation and openstack project does nto provided third party rpm or deb repos for our releasese. we do provide tar balls and help distos do packaging but we do not deliver them as part of the official deliverables. most opentack python porject have a statement like this in the scope of the poject section https://docs.openstack.org/nova/latest/contributor/project-scope.html#deploy... which declare providing packages as out of scope of the porjects. the only package artificats we produces are the tarballs and pypi packages.

My understanding of packaging is not very deep, so I would greatly appreciate any guidance or insights you can provide on this matter.

Looking forward to your insights.

Best regards, Han Guangyu