Open Stack

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.


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

Packages do not lose any of their value when used inside containers, and
the same arguments apply to this case. And no, let's not seriously talk
about pip install.


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

Metal3 is OpenShift, not OpenStack. You're suggesting exactly the thing
that turns people against Ironic: require OpenStack.

Dmitry


> 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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200406/9b71ecf3/attachment.html>