On 19-05-22 23:53:50, Jeremy Stanley wrote:
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).
I don't know if we only care about certain things. But if we go forward with this accepting changes that pass tests and go into another constraints file (not upper-constraints) and not actively submitting them ourselves. More opportunistic then active on our part. The other constraints file should have a LARGE warning saying that this is not a substitute for actual security backports as it is not complete (is opportunistic). -- Matthew Thode