Open Stack

On 2015-08-05 16:08:16 +0000 (+0000), Reshetova, Elena wrote:
[...]
> Actually the database is downloaded only once ( thefirst time) and
> then only database diffs are downloaded, which is much faster. I
> don't know enough about your node setup (do you fully clean up
> each node between the builds?) and etc., so the best way to test
> this would be if somebody can try it out and tell if it is a
> problem. If it is a problem, then we can discuss with the tool
> maintainer on how to address it.
[...]

Yes, we actually don't reuse job workers. We run each job in a fresh
virtual machine, delete it when complete and launch a new VM to take
its place. Thus the database would need to be downloaded as part of
the job, or pre-cached in the worker images we boot, or part of some
remote query service so that we don't have to have the entire
database local to the job runner.

> I am actually a bit confused why this file for example called
> "upper-constraints"? The name would indicate an upper border, but
> that doesn't make that much sense with packaging systems.
[...]

It is the maximum available version of each of our dependencies,
calculated by the Python packaging tool "pip" when attempting to
resolve mutually coinstallable versions of declared dependency
version ranges within the transitive set (which is nontrivial to
identify without recursively downloading and installing those
packages since they embed their dependency information, can
sometimes only determine it at runtime, and vary dependencies by
interpreter version as well).

That is to say, the upper-constraints.txt file lists the maximum
versions of dependencies you can possibly run our software with when
installed with the normal Python packaging toolchain. I don't see
where it would make sense to test for vulnerabilities in older
versions of dependencies anyway since it's not up to us to notify
end users of bugs in software we don't distribute unless it actually
prevents our software from running.
-- 
Jeremy Stanley