On 2020-03-19 09:26:23 + (+), 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