Open Stack

On 2019-12-13 18:01:03 +0100 (+0100), Thierry Carrez wrote:
[...]
> 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
> 
> 2- rewrite the Python script so that it can run on stdlib -- not sure I want
> to write a YAML parser from scratch though
> 
> 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
> 
> Other ideas?

Stepping back and thinking about the overall goal (at least what I
recall originally discussing), you basically want to look at what
the change proposes to update in the releases repo, join that with
project information in openstack-governance to get the list of
liaisons, then contact Gerrit and add those liaisons as requested
reviewers on the change or leave a review comment listing them (or
maybe both), right?

Assuming that's the case, the repos and Git and pyyaml are available
to the workspace on the executor easily enough. Gerrit has a REST
API and we have requests already importable too if Ansible's
built-in HTTP module isn't sufficiently flexible... is that enough
to get it done? That's basically what I was thinking about when I
originally suggested a job "lightweight enough to run on the
executor." I assumed it would work similar to some other jobs we
already have which use an Ansible playbook to call a remote REST API
with some supplied credentials based on some information in a
change.

Speculatively testing changes to the job will be tough of course
because of the need to avoid leaking the Gerrit secret, but that's
going to be the case with any playbook which needs to authenticate
to a remote service.
-- 
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/20191213/bbad9030/attachment-0001.sig>