Open Stack

On 2019-05-23 02:24:02 +0200 (+0200), Dirk Müller wrote:
[...]
> 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.
[...]

I'm also not sure running a second copy of *all* our jobs is
sensible either. A balance must be struck for testing enough that
we'll catch likely issues while acknowledging that we simply can't
test everything.

> So running safety against our stable branch spills out this list
> of packages:
[...]

Out of curiosity, which branch was it? Stein? Rocky? Queens? I have
a feeling the further back you go, the longer that list is going to
get. Also as the safety tool grows in popularity it may see
increased coverage for less common, more fringe dependencies.

> transitive changes are not needed if we have backports in the
> gate.
[...]

I'm not sure what that means. Can you rephrase it?

> 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.
[...]

Not all projects have lower constraints jobs, and they aren't
required to use consistent versions, so running integration tests
with lower constraints is a non-starter and therefore not a
replacement for the frozen central upper-constraints.txt file.

> 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?

http://lists.openstack.org/pipermail/openstack-discuss/2019-May/006087.html

Apparently we don't have to claim it's a secure deployment solution
for some operators to just assume it is. I'm saying as a community
we need to do a better job of communicating to our users that
production deployments from stable branch sources need to get their
external dependencies from a security-managed platform, that
installing the versions we test with is not and ultimately *can not*
be secure. This is similar to the concerns raised with the TC which
resulted in the 2017-05-30 Guidelines for Managing Releases of
Binary Artifacts resolution:

https://governance.openstack.org/tc/resolutions/20170530-binary-artifacts.html

Adding comments in our constraints files is certainly one measure we
can (and likely should) take, but more importantly we need our
deployment projects who provide such options to get the word out
that this model of operation is wholly unsuitable for production
use.
-- 
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/20190523/472a8535/attachment.sig>