Re: [PATCH v5 2/4] Jobs based on custom runners: build environment docs and playbook

[Cleber Rosa <crosa@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3658 bytes --]

On Tue, Feb 23, 2021 at 03:51:33PM +0100, Erik Skultety wrote:
> On Tue, Feb 23, 2021 at 02:01:53PM +0000, Alex Bennée wrote:
> > 
> > Cleber Rosa <crosa@redhat.com> writes:
> > 
> > > To run basic jobs on custom runners, the environment needs to be
> > > properly set up.  The most common requirement is having the right
> > > packages installed.
> > >
> > > The playbook introduced here covers the QEMU's project s390x and
> > > aarch64 machines.  At the time this is being proposed, those machines
> > > have already had this playbook applied to them.
> > >
> > > Signed-off-by: Cleber Rosa <crosa@redhat.com>
> > > ---
> > >  docs/devel/ci.rst                      | 30 ++++++++++
> > >  scripts/ci/setup/build-environment.yml | 76 ++++++++++++++++++++++++++
> > >  scripts/ci/setup/inventory             |  1 +
> > >  3 files changed, 107 insertions(+)
> > >  create mode 100644 scripts/ci/setup/build-environment.yml
> > >  create mode 100644 scripts/ci/setup/inventory
> > >
> > > diff --git a/docs/devel/ci.rst b/docs/devel/ci.rst
> > > index 585b7bf4b8..a556558435 100644
> > > --- a/docs/devel/ci.rst
> > > +++ b/docs/devel/ci.rst
> > > @@ -26,3 +26,33 @@ gitlab-runner, is called a "custom runner".
> > >  The GitLab CI jobs definition for the custom runners are located under::
> > >  
> > >    .gitlab-ci.d/custom-runners.yml
> > > +
> > > +Machine Setup Howto
> > > +-------------------
> > > +
> > > +For all Linux based systems, the setup can be mostly automated by the
> > > +execution of two Ansible playbooks.  Start by adding your machines to
> > > +the ``inventory`` file under ``scripts/ci/setup``, such as this::
> > > +
> > > +  fully.qualified.domain
> > > +  other.machine.hostname
> > 
> > Is this really needed? Can't the host list be passed in the command
> > line? I find it off to imagine users wanting to configure whole fleets
> > of runners.
> 
> Why not support both, since the playbook execution is not wrapped by anything,
> giving the option of using either and inventory or direct cmdline invocation
> seems like the proper way to do it.
>

Well, these two (and possibly many others) are supported by
ansible-playbook.  I don't think we should document more than one
though, as it leads to a more confusing documentation.

> > 
> > > +
> > > +You may need to set some variables in the inventory file itself.  One
> > > +very common need is to tell Ansible to use a Python 3 interpreter on
> > > +those hosts.  This would look like::
> > > +
> > > +  fully.qualified.domain ansible_python_interpreter=/usr/bin/python3
> > > +  other.machine.hostname ansible_python_interpreter=/usr/bin/python3
> > > +
> > > +Build environment
> > > +~~~~~~~~~~~~~~~~~
> > > +
> > > +The ``scripts/ci/setup/build-environment.yml`` Ansible playbook will
> > > +set up machines with the environment needed to perform builds and run
> > > +QEMU tests.  It covers a number of different Linux distributions and
> > > +FreeBSD.
> > > +
> > > +To run the playbook, execute::
> > > +
> > > +  cd scripts/ci/setup
> > > +  ansible-playbook -i inventory build-environment.yml
> > 
> > So I got somewhat there with a direct command line invocation:
> > 
> >   ansible-playbook -u root -i 192.168.122.24,192.168.122.45 scripts/ci/setup/build-environment.yml -e 'ansible_python_interpreter=/usr/bin/python3'
> > 
> > although for some reason a single host -i fails...
> 
> The trick is to end it with a ',' like "-i host1,"
>

Yep, that is the trick!  A weird one nevertheless... :)

> Erik

Thanks for the review and comments so far Erik!

Best,
- Cleber.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]