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