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.ht... 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