Open Stack

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190522/f65574b5/attachment.sig>