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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev