Bug 1650550

(In reply to Till Maas from comment #0)

> Additional info:
> 
> The names for the roles need to be normalized to use
> linux-system-roles.$subsystem for this to work. Some roles might not yet do
> this.

Could they be normalized to {{ prefix }}.$subsystem and prefix be set to rhel-system-roles or linux-system-roles as appropriate? Otherwise I will have to transform them with sed, which will be a bit annoying.

Since the rhel-system-roles also package the compat symlinks, sed would not be necessary. A variable could be possible but I do not see how to auto-detect the correct value and where. To make them work by themself, they should have a default value for linux-system-roles but then if you care about the files on disk, then this would need to be changed using sed anyhow.

(In reply to Till Maas from comment #2)
> Since the rhel-system-roles also package the compat symlinks, sed would not
> be necessary. 

We document using the rhel-system-roles prefix though, so that's what we should test downstream.

> but then if you care
> about the files on disk, then this would need to be changed using sed anyhow.

I don't understand this part.

(In reply to Pavel Cahyna from comment #3)
> (In reply to Till Maas from comment #2)

> > but then if you care
> > about the files on disk, then this would need to be changed using sed anyhow.
> 
> I don't understand this part.

Somehow the prefix needs to be defined. So either it always needs to be specified when running ansible-playbook or the tests would use the linux-system-roles prefix by default. If the files are packaged, the packaged files will also use this prefix by default unless it is changed via sed. The downstream test could then specify a different prefix but the files on the disk would still contain the upstream prefix.

If it is a variable, we can supply the prefix by another means than changing the default in the file(s) via sed. E.g. -e argument to ansible-playbook.

(In reply to Pavel Cahyna from comment #5)
> If it is a variable, we can supply the prefix by another means than changing
> the default in the file(s) via sed. E.g. -e argument to ansible-playbook.


yes, if this is sufficient, we can do something like


# SPDX-License-Identifier: BSD-3-Clause
---
- name: Test executing the role with default parameters
  hosts: all
  roles:
    - "{{ role_prefix | default('linux-system-roles') }}.network"

Then role_prefix can be overridden with -e role_prefix=rhel-system-roles. Nevertheless, the files in the package will still state linux-system-roles.

Note: the symlinks are not strictly required upstream - the CI can be made to work without them, and it might be preferable from some POV - but Till argues that they are very useful for developers for local testing.

(In reply to Till Maas from comment #6)
> (In reply to Pavel Cahyna from comment #5)
> > If it is a variable, we can supply the prefix by another means than changing
> > the default in the file(s) via sed. E.g. -e argument to ansible-playbook.
> 
> 
> yes, if this is sufficient, we can do something like
> 
> 
> # SPDX-License-Identifier: BSD-3-Clause
> ---
> - name: Test executing the role with default parameters
>   hosts: all
>   roles:
>     - "{{ role_prefix | default('linux-system-roles') }}.network"
> 
> Then role_prefix can be overridden with -e role_prefix=rhel-system-roles.
> Nevertheless, the files in the package will still state linux-system-roles.

In case of using a wrapper that imports role, role_prefix can be determined dynamically depending on the value of ansible_distribution, but at the end there still be 'linux-system-roles' string present in RPM. The question is if having 'linux-system-roles' in RPM is issue or not. Supposing that the goal of role_prefix is to provide the capability of testing system roles in the same manner like customers use them, the first few tasks in role wrapper can be:

- name: Ensure role name is defined
  assert:
    that:
      - role_name is defined
    fail_msg: >
      Please specify the name of the role you wish to use
      by setting the role_name variable.

# Task will be skipped when role_prefix is provided by e.g. CI
- name: Guess the role prefix (first try)
  set_fact:
    role_prefix: "rhel-system-roles"
  when:
    - role_prefix is not defined
    - ansible_distribution == "RedHat"

- name: Guess the role prefix (second try)
  set_fact:
    role_prefix: "linux-system-roles"
  when:
    - role_prefix is not defined
    - ansible_system == "Linux"

- name: Verify the role prefix has been set properly
  assert:
    that:
      - role_prefix is defined
      - role_prefix in ['linux-system-roles', 'rhel-system-roles']
    fail_msg: >
      Please specify if {{ role_name }} is linux-system-roles.{{ role_name }}
      or rhel-system-roles.{{ role_name }} by setting the role_prefix to
      either 'linux-system-roles' or 'rhel-system-roles'.

Also notice that sometimes ansible_distribution may not provide valid information, see https://github.com/ansible/ansible/issues/10937.

If we wish to have no 'linux-system-roles' string in files that are distributed in package, then we can use just {{ role_prefix }} without fallback to default value. In this case, role_prefix must be always provided by CI. To make this work when testing locally, symlinks should be renamed to just $subsystem instead of linux-system-roles.$subsystem and the first lines in wrapper can be:

- name: Ensure role name is defined
  assert:
    that:
      - role_name is defined
    fail_msg: >
      Please specify the name of the role you wish to use
      by setting the role_name variable.

- name: Guess full role name
  set_fact:
    full_role_name: "{{ (role_prefix is defined) | ternary(role_prefix + '.', '') }}{{ role_name }}"

Note that both solutions proposed above rely on importing role via wrapper.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (rhel-system-roles bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2021:1909