[tc][election] Simple question for the TC candidates

Radosław Piliszek radoslaw.piliszek at gmail.com
Tue Apr 7 17:48:41 UTC 2020


Hey fungi,

Jeremy Stanley <fungi at yuggoth.org> wrote:
> Just to be clear, we didn't add rules about coinstallability to make
> *our* upstream lives easier. We did it so that downstream distros
> don't have to provide and support multiple versions of various
> dependencies.

Indeed, these are not for us but for potential downstreams.

> What you're in effect recommending is that we stop
> supporting installation within traditional GNU/Linux distributions,
> since only package management solutions like Docker or Nix are going
> to allow us to punt on coinstallability of our software.

I think you are taking this a bit too far.
System-wide site-packages are an inherently flawed mechanism.
Inability to have two different versions of the same library/program
is due to this, not packaging.
Distros already ship different versions of lower-level libraries, with
differing ABI.
Sometimes they separate the things in loadable modules with proper
dynamic linking chains.
In Python similar can be achieved with venvs (and I know you know that).
They exist for a purpose and this is the one.
Also, those same distros ship other Python projects, we can never ensure
this level coinstallability with them even if they could enhance the
overall service experience.
What is done then? Isolation. :-)
Same story if said distro needs to ship some old version of Python
package for its internal usage.

> You're
> *also* saying that our libraries now have to start supporting users
> on a broader variety of their own old versions, and also
> support/test working with a variety of different versions of their
> own dependencies, or that we also give up on having any abstracted
> Python libraries and go back to re-embedding slightly different
> copies of the same code in all OpenStack services.

No, why?
Voting for containerization and abandonment of strict coinstallability
enforcement does not invalidate the purpose of these.
Again, the strength is in well-defined interfaces, not reliance on
exact versions of every library.
Program to interfaces, test the interfaces, live a happy life.


All that said, I am not for dropping this all right away.
This needs to take time and *will* take considerable time for sure.
There could be a staged approach where we allow projects to drop out
of coinstallability constraint (looking at Ironic now).

Separate thing is that not all OpenStack software is packaged in the
main distros.
So in their case this is just wishful thinking: package me, I'm ready
for the traditional packaging world where we drop everything in one
big namespace*. :-)
For reference you can inspect the non-buildability patterns of Kolla
for the binary flavor:
common (rhel+debuntu):
https://opendev.org/openstack/kolla/src/commit/f1f1d854594da23321ad94ae6358ecbdc119d18e/kolla/image/build.py#L106-L123
debuntu specific extra:
https://opendev.org/openstack/kolla/src/commit/f1f1d854594da23321ad94ae6358ecbdc119d18e/kolla/image/build.py#L199-L230

* As long as you only care about OpenStack because I'm gonna break your X.


-yoctozepto



More information about the openstack-discuss mailing list