On 2019-05-23 01:09:58 +0200 (+0200), Dirk Müller wrote:
Hi Jeremy,
Doing conformance testing on those distros with their packaged versions of our external dependencies would much more closely approximate what I think you want
I think that would also work. Would the community be interested in solving conformance incompatibilities when purely vendored versions are used? I somehow have doubts. Would we track the vendored version/releases in a constraints file to ensure gating issues are not creeping in?
I don't know that we need to if the goal is to let us know (e.g. with a periodic job) that a distro we care about has upgraded a dependency in a way that our stable branch targeting that distro version no longer works with.
All the existing tooling is around tracking lower and upper constraints as defined by pip and our opendev defined wheel mirrors.
Unless we have a tool that translate pip install commands into the respective distribution equivalent, such a vendored-test also adds significant drag for projects : maintaining two different ways to install things and for X number of vendors to cross-check and help debug solve integration issues. Plus the amount of extra CI load this might cause. Not a fun task.
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.
Considering that I would prefer to volunteer maintaining a pypi/pip wheel fork of the ~5 dependencies with security vulnerabilities that we care about and pull those in instead of exposing the full scope of X vendors downstream specific patching issues to us as a community.
Do we really only care about 5 out of our many hundreds of external Python dependencies? Or is it that we should assume over years of maintenance, fewer than one percent of them will discover vulnerabilities? At any rate, I'm not opposed to the experiment as long as we can still also run jobs for our original frozen dependency sets (so that our stable branches don't inadvertently develop a requirement for a new feature in newer versions of these dependencies) *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). -- Jeremy Stanley