Policy rule for ownership between remote and executor

Change-Id: Ia0b6bcf221ee053a0c2a2073796cba35fa22efd0
This commit is contained in:
Albin Vass 2020-05-01 16:33:24 +02:00
parent b8a24d635f
commit 38053b0826
2 changed files with 61 additions and 31 deletions

View File

@ -10,7 +10,7 @@ Check for tasks that does not follow
the policy of namespacing loop variables with zj_ prefix. the policy of namespacing loop variables with zj_ prefix.
See: \ See: \
https://zuul-ci.org/docs/zuul-jobs/policy.html\ https://zuul-ci.org/docs/zuul-jobs/policy.html\
#ansible-loops-in-roles #loops-in-roles
""" """
tags = {'zuul-jobs-namespace-loop-var'} tags = {'zuul-jobs-namespace-loop-var'}

View File

@ -153,29 +153,17 @@ If relevant, the specific steps where the privilege escalation occurs should be
documented so that they can be reproduced when configuring hosts. If possible, documented so that they can be reproduced when configuring hosts. If possible,
they should be grouped in a separate playbook that can be applied to hosts manually. they should be grouped in a separate playbook that can be applied to hosts manually.
Ansible Loops in Roles Output Variables
********************** ****************
Because the Ansible roles contained in this repo are expected to be Some roles may find it useful to set a variable that can be consumed
pretty universally applicable in Zuul systems we must write them by later roles. For example, the `ensure-pip` role sets a variable
defensively to work around some Ansible behaviors. In particular which specifies a working `virtualenv` command for the host.
nesting Ansible loops using the default `loop_var` of `item` is not
safe.
Roles in this repo should override the default `loop_var` in loops Roles should document their output under the **Output** section of
and use a variable name prefixed with `zj_` to make them more unique. their README documentation. The variable should use the `cacheable:
The idea is this will avoid conflicts with the calling level which true` flag to `set_fact` to ensure that the variable is available
may use `include_role` in a loop creating a `loop_var` conflict. across playbooks.
For example::
command: echo {{ zj_number }}
loop:
- one
- two
- three
loop_control:
loop_var: zj_number
Installing Dependencies in Roles Installing Dependencies in Roles
******************************** ********************************
@ -197,17 +185,59 @@ Here are the ways to install dependencies in order of preference:
In any case, the role's documentation should mention which dependencies are In any case, the role's documentation should mention which dependencies are
needed, allowing users to prepare their hosts accordingly. needed, allowing users to prepare their hosts accordingly.
Output Variables Ansible Linting Rules
**************** *********************
Some roles may find it useful to set a variable that can be consumed Because the Ansible roles contained in this repo are expected to be
by later roles. For example, the `ensure-pip` role sets a variable pretty universally applicable in Zuul systems, we must write them
which specifies a working `virtualenv` command for the host. defensively to work around some Ansible behaviors.
Custom rules for ansible-lint have been set up to enforce this.
Roles should document their output under the **Output** section of Loops in Roles
their README documentation. The variable should use the `cacheable: ^^^^^^^^^^^^^^
true` flag to `set_fact` to ensure that the variable is available
across playbooks. Nesting Ansible loops using the default ``loop_var`` of ``item`` is not
safe.
Roles in this repo should override the default ``loop_var`` in loops
and use a variable name prefixed with ``zj_`` to make them more unique.
The idea is this will avoid conflicts with the calling level which
may use ``include_role`` in a loop creating a ``loop_var`` conflict.
For example::
command: echo {{ zj_number }}
loop:
- one
- two
- three
loop_control:
loop_var: zj_number
Preservation Of Owner Between Executor And Remote
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Since it's not possible to make sure the user and group on the
remote node also exists on the executor and vice versa, owner and
group should not be preserved when transfering files between them.
For example when using the synchronize module set owner and group
to ``false``::
synchronize:
dest: /tmp/log.txt
src: /tmp/log.txt
owner: false
group: false
And when using the unarchive module add ``--no-same-owner`` to
extra-ops::
unarchive:
dest: ~/example
src: /tmp/example.tar.gz
extra_ops:
- '--no-same-owner'
Testing Testing
------- -------