On Mon, 2020-04-06 at 15:10 +0200, Thierry Carrez wrote:
Sean Mooney wrote:
On Mon, 2020-04-06 at 13:14 +0200, Dmitry Tantsur wrote:
On Mon, Apr 6, 2020 at 1:03 PM Sean Mooney <smooney@redhat.com> wrote:
On Mon, 2020-04-06 at 10:10 +0200, Dmitry Tantsur wrote:
The problem is that oslo libraries are OpenStack-specific. Imagine
metal3,
for example. When building our images, we can pull (most of) regular
Python
packages from the base OS, but everything with "oslo" in its name is on
us.
It's a maintenance burden.
what distros dont ship oslo libs?
RHEL ships them via the OSP repos
As part of OpenStack, right.
CentOS ship it via RDO Ubunutu has them in the cloud archive SUSE also shiped them via there openstack product although sicne they are nolonger maintaining that goign forward and moveing the k8s based cloud offerings it might be a valid concern there.
All the same here: oslo libs are parts of OpenStack distributions/offerings. Meaning that to install Ironic you need to at least enable OpenStack repositories, even if you package Ironic yourself.
ya that is true although i think oslo is also a good candiate for standablone reuse outside of openstack. like placment keystone and ironic are. so in my perfered world i would love to see oslo in the base os repos.
What's preventing that from happening ? What is distro policy around general-purpose but openstack-community-maintained Python libraries like stevedore or tooz ?
FWIW in Ubuntu all oslo libraries are packaged as part of the "base OS repos", and therefore indistinguishable from other Python libraries in terms of reuse. The 'cloud archive' is just an additive repository that allows older LTS users to use the most recent OpenStack releases. i think fedora ships them in the base os too https://src.fedoraproject.org/rpms/python-oslo-config and if im reading this rgiht i think opensuse does too https://build.opensuse.org/repositories/openSUSE:Factory/python-oslo.config
i suspect from a redhat perspective it was just a reflection our org stucture or there may have been a business decision at play. through the use of modules in the new buidl system on rhel8 its perfectly possible for RHEL to provide a version of a package and the openstack product to provide an different version on a different delivery cadence. we do this for libvirt via the advnced virt module but form a technicall perspective i dont think there is fundamentally an issue with that other then manpower and this is how its currently done. RDO certenly is a factor as if we move too packaging them in centos main repos instead of rdo there would have to be some collaberation there to enable it to work smothly. currently tooz and the rest of oslo are deliver as part of the centos cloud sig https://cbs.centos.org/koji/buildinfo?buildID=25866 consuming the output of the rdo project. https://wiki.centos.org/SpecialInterestGroup/Cloud i would expect kubernets/openshift orgin to be part of that too although apparently it is not.