Open Stack

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 at 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.

>