On 2020-03-19 09:26:23 +0000 (+0000), Sorin Sbarnea wrote: [...] > I know that we already had talks about migrating zuul-jobs to > install tools inside virtualenvs but this did not happen yet.
It actually has, tox is already available /usr/tox-env/bin/tox on our systems, we just haven't yet merged the change to stop installing a copy of tox into the system context (but that's coming). There's also a /usr/bindep-env/bin/bindep, a /usr/os-testr-env/ostestr and a /usr/glean/bin/glean (that last one could stand to become consistent with the others, I suppose). > I was told that the idea was to install each tool into each own > virtulaenv in order to better isolate it from conflicts with > others but I have some concerns regarding : > > a) making very hard or even impossible to use multiple tools in > the same script, as they would exist in different envs. We're talking about installing Python-based utilities into dedicated venvs. What you note is a concern for Python libraries. When is the last time you "imported" tox in a Python script? How about bindep? Remember that tox in one venv can call bindep from another venv just fine because those are being treated as command-line tools not Python modules (it's how I run them together on my own workstation even). Things which need to import each other should of course be installed into the same venv, that's just common sense. > b) extra footprint on disk and install time. [...] We're not planning on pre-installing more than a handful. Our node images are around 9GB in size, most of which is pre-cached data (Git repositories), and the venvs I listed account for 24KB of excess copies of files. That's something like a quarter of one percent of the image size you're concerned about optimizing. > There are lots of places in tripleo* where pip --user is used and > before trying to propose any changes there, I would like to know > where are we going towards with zuul-jobs as I would like to avoid > divergence in behaviours. If TripleO is installing things at job runtime, that seems like a different case than whatever we bake into our node images, and so doing it a different way is probably fine? -- Jeremy Stanley
signature.asc
Description: PGP signature
_______________________________________________ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
