Open Stack

Hi Jeremy,

> DevStack used to support this, but it does indeed seem to have been
> refactored out some time ago. Reintroducing that, or something like
> it, could be an alternative solution though.

Most of interesting test coverage is in the project's functional test jobs
as well, so "just" devstack alone isn't enough, all the projects need
to support this
variation as well.

> Do we really only care about 5 out of our many hundreds of external
> Python dependencies?

So running safety against our stable branch spills out this list of packages:

ansible-runner
cryptography
django
numpy
msgpack
pyOpenSSL
urllib3
requests

plus transitive (docker, zhmcclient, kubernetes). numpy is hopefully to
ignore in our use case, and django is used unconstrained anyway in the gate,
so I would imho remove it from this list. msgpack is an API change, so
unsuitable
as well. transitive changes are not needed if we have backports in the
gate. so this totals in ~5
packages to maintain. I am not looking at branches that are under
extended maintenance fwiw.

> dependency sets (so that our stable branches don't inadvertently
> develop a requirement for a new feature in newer versions of these
> dependencies)

lower-constraints.txt jobs try to ensure that this won't happen,
assuming that we somehow bump
the version numbers to X.X.X.post1, so thats not an additional thing
to worry about.

> *and* as long as we make it clear to users that this
> is not a substitute for running on security-supported distro
> packages (where someone more accountable and read-in than the
> OpenStack project is backporting patches for vulnerabilities to
> forks of those dependencies).

I'm not aware of any statement anywhere that we'd be security
maintaining a distro?
Where would we state that? in the project's documentation/README?

Greetings,
Dirk