Open Stack

Thierry Carrez <thierry at openstack.org> writes:

> I moved to implementation on this, but I hit an issue with the
> original plan:
>
>> [...]
>> The job should be lightweight enough to run on the executor. With
>> all those safeguards in place, I do not expect it to trigger
>> significant additional load.
>
> My current implementation is a python script run from tox. But I can't
> use the standard tox jobs as they have "hosts:all" tasks all over them
> which are bypassed[1] if the job is run on the executor.
>
> [1] See
> https://zuul.opendev.org/t/openstack/build/4056ca3ee8b247ebbe1cbb1474191c16/console
>
> Ideally I would define my own narrow playbook to run the script,
> without inheriting from the standard tox job. However the current
> script requires some dependencies to be installed
> (openstack-governance, yaml...).
>
> Here are the options I see:
>
> 1- reimplementing most of the unittests/tox job logic in
> "hosts:localhost" playbook(s) -- would mean lots of copypaste, does
> not rhyme so well with "lightweight", and increases execution times
> significantly

On the contrary, this is quite simple.  The jobs in zuul-jobs are
designed to have very simple playbooks which are typically just lists of
roles.  Our goal was to make them as much like using JJB as possible.

These are the 2 playbooks involved:

  https://opendev.org/zuul/zuul-jobs/src/branch/master/playbooks/tox/pre.yaml
  https://opendev.org/zuul/zuul-jobs/src/branch/master/playbooks/tox/run.yaml

Ultimately the entire job is just a list of 4 roles:

  - ensure-tox
  - ensure-python
  - revoke-sudo
  - tox

Please feel free to make a job with whatever role combination you need.

If you plan to run on the executor, you do not need ensure-python; we
know it's there.  Nor do you need revoke-sudo; we know we don't have
sudo.

On the other hand, Zuul restricts what can be run on the executor by
playbooks in untrusted repos, and executing a subprocess like tox is one
of the restricted actions, so if you did make a "hosts: localhost"
playbook, it would not work if run out of the releases repo.  It would
need to be put in the project-config repo, and changes to the job would
not be self-testing.  But if you've got this mostly working already,
that's probably not a big deal.

But back on the first hand, I think that installing python packages in a
virtualenv is too heavyweight for a job to run on the executor.  The
candidates we usually look for are things that can run with what's
already installed.  Happily, yaml is already installed, because it's
kind of a big deal on the executor.  Unhappily, openstack-governance is
not merely a repo you need to have on-disk, but is actually a python
package you need installed (wow, when did that happen?).

We were so close.  If you just needed to run a python script that
imported yaml and read a file out of governance, I'd say it would be a
great candidate for running on the executor.  But I think the
installation of openstack-governance (which has its own requirements
that are not installed on the executor) pushes this over the line, and
we should run it on a full node.

> 2- rewrite the Python script so that it can run on stdlib -- not sure
> I want to write a YAML parser from scratch though

If you want to drop the dependency on openstack-governance and rewrite
the "business logic" parts of that without rewriting the yaml parsing
parts (since PyYAML is installed), then the above is a viable option.

> 3- Abandon the idea of running on the executor -- the trick is that
> for such a short job the overhead of requesting a test node is a bit
> heavy, and we want to run the job on every vote change on release
> requests

Maybe #2 is worth it then?

-Jim