Open Stack

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