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 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. they are also directly installable via pip. building rpms in the first place is a mangaince burden you do not need if you are doing containerised delivery they only add value if you are supporting non containerised delivery via standard package manages. so for metal3 i dont see that as a vaild argument as in your case redhat is already going to be doing the packageing for the OSP product line irrispective of the supprot/sale of metal3 in a product so using olso wont have any additional downstream cost. form a distro/downstream perpective we still need to maintain the python libs so using oslo is no larger burden the using a different pip lib that is not already packaged in rhel.