Open Stack

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20200319/7694e597/attachment.sig>