We have a lot of requests to support Rocky and Alma in various system roles. The
first part of adding support is adding `vars/` files for these platforms. In
almost every case, for a given major version N, the vars file RedHat_N.yml can
be used for CentOS, Rocky, and Alma. Rather than making a copy of the
RedHat_N.yml file, just use a symlink to reduce size and maintenance burden, and
standardize this across all system roles for consistency.
NOTE: There is no Alma or Rocky version 7 or less.
NOTE: OracleLinux is not a strict clone, so we are not going to do this for
OracleLinux at this time. Support for OracleLinux will need to be done in
separate PRs. For more information, see
https://github.com/linux-system-roles/cockpit/issues/130
**Question**: Why not just use `ansible_facts["os_family"] == "RedHat"`?
**Answer**: This is what Ansible uses as the RedHat os_family:
1e6ffc1d02/lib/ansible/module_utils/facts/system/distribution.py (L511)
There are a lot of distributions in there. I know that Fedora is not a clone of
RHEL, but it is very closely related. Most of the others are not clones, and it
would generally not work to replace ansible_distribution in ['CentOS', 'Fedora',
'RedHat'] with ansible_facts['os_family'] == 'RedHat' (but it would probably
work in specific cases with specific distributions). For example, OracleLinux
is in there, and we know that doesn't generally work. The only ones we can be
pretty sure about are `RedHat`, `CentOS`, `Fedora`, `AlmaLinux`, and `Rocky`.
**Question**: Does my role really need this because it should already work on
RHEL clones?
**Answer**: Maybe not - but:
* it doesn't hurt anything
* it's there if we need it in the future
* the role will be inconsistent with the other system roles if we don't have this
**Question**: Why do I need the `tests/vars/rh_distros_vars.yml` file? Doesn't
the test load the vars from the role?
**Answer**: No, the test does not load the vars from the role until the role is
included, and many tests use version and distribution before including the role.
**Question**: Do we need to change the code now to use the new variables?
**Answer**: No, not now, in subsequent PRs, hopefully by Alma and Rocky users.
Note that there may be more work to be done to the role to fully support Rocky
and Alma. Many roles have conditionals like this:
```yaml
some_var: "{{ 'some value' if ansible_distribution in ['CentOS', 'RedHat'] else 'other value' }}"
another_var: "{{ 'some value' if ansible_distribution in ['CentOS', 'Fedora', 'RedHat'] else 'other value' }}"
...
- name: Do something
when: ansible_distribution in ['CentOS', 'RedHat']
...
- name: Do something else
when: ansible_distribution in ['CentOS', 'Fedora', 'RedHat']
...
```
Adding Rocky and AlmaLinux to these conditionals will have to be done
separately. In order to simplify the task, some new variables are being
introduced:
```yaml
__$rolename_rh_distros:
- AlmaLinux
- CentOS
- RedHat
- Rocky
__$rolename_rh_distros_fedora: "{{ __$rolename_rh_distros + ['Fedora'] }}"
__$rolename_is_rh_distro: "{{ ansible_distribution in __$rolename_rh_distros }}"
__$rolename_is_rh_distro_fedora: "{{ ansible_distribution in __$rolename_rh_distros_fedora }}"
```
Then the conditionals can be rewritten as:
```yaml
some_var: "{{ 'some value' if __$rolename_is_rh_distro else 'other value' }}"
another_var: "{{ 'some value' if __$rolename_is_rh_distro_fedora else 'other value' }}"
...
- name: Do something
when: __$rolename_is_rh_distro | bool
...
- name: Do something else
when: __$rolename_is_rh_distro_fedora | bool
...
```
For tests - tests that use such conditionals will need to use `vars_files` or
`include_vars` to load the variables that are defined in
`tests/vars/rh_distros_vars.yml`:
```yaml
vars_files:
- vars/rh_distros_vars.yml
```
We don't currently have CI testing for Rocky or Alma, so someone wanting to run
tests on those platforms would need to change the test code to use these.
Signed-off-by: Rich Megginson <rmeggins@redhat.com>
As part of the public API, `network_state` must be defined in
defaults/main.yml, and it must be defined with the correct
type `dict`, so the correct default value must be `{}` the
empty dict.
All checking for `network_state` must check for a value of
`{}` to mean "network_state not set or empty".
Fix the test which looks for teaming configuration in EL10
to correctly look for the value in `network_state`.
Signed-off-by: Rich Megginson <rmeggins@redhat.com>
Initscripts provider requires `/sbin/dhclient` to obtain DHCP address,
which is shipped in dhcp client package. But the managed hosts may not
already install the dhcp client package, thus, add it as the dependency
package for initscripts provider.
Signed-off-by: Wen Liang <liangwen12year@gmail.com>
Cause: The comparison of the present facts with the required facts is
being done on unsorted lists.
Consequence: The comparison may fail if the only difference is the
order. Facts are gathered unnecessarily.
Fix: Use `difference` which works no matter what the order is. Ensure
that the fact gathering subsets used are the absolute minimum required.
Result: The role gathers only the facts it requires, and does
not unnecessarily gather facts.
Signed-off-by: Rich Megginson <rmeggins@redhat.com>
ansible-core 2.14 is now the current version of Ansible. This version
does not support `args: warn: false` so we have to remove it from the
network role. Users will need to use `COMMAND_WARNINGS` in their
Ansible configuration in order to suppress the warning in older versions
of Ansible such as 2.9, 2.11.
In addition, the gating tests are getting stricter about using new best
practices, such as using `true`, `false` for booleans instead of `yes`,
`no`; use of spaces in Jinja expressions; etc. These issues were
addressed.
The `tests/` directory contains far too many cases of non-recommended
practices, so this directory has been exempted.
Signed-off-by: Rich Megginson <rmeggins@redhat.com>
Some users prefer to use `gather_facts: false` in their playbooks.
However, the network role requires certain ansible_facts to be set. If
the user wants to use the network role with `gather_facts: false`, the
role will gather the minimum subset of facts required. If the user does
not want the role to gather facts, the user can either not use the
network role, or ensure that all required facts are in the facts cache.
Signed-off-by: Rich Megginson <rmeggins@redhat.com>
WPA-PSK and WPA-EAP are supported. Uses existing 802.1x features of the role.
Added extra functionality to ArgValidatorStr to enforce a min and max length.
To avoid conflicts with other roles, it is recomended to prefix all variables
that are only used internally with '__' and the name of the role ('__network_').
This patch implements the ETHTOOL_GPERMADDR command in order to retrieve
the permanent address from ethtool instead using command line tool.
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
Some tests were getting the following error:
```
Unexpected templating type error occurred on ({{
network_connections |
json_query('[*][ieee802_1x]') | flatten | count > 0 }}): 'NoneType'
object is not iterable"
```
In general it is better to avoid the use of `json_query` and use
the older built-in jinaj2 filters such as `selectattr`, unless you
need to perform a complex query of complex json data. In this
case, not sure what the problem was with the input json, but
using `selectattr` seems to have fixed it.
- Amend and add files to run integration tests against the provider that
was not autodetected, too.
- Add check to ensure that all integration tests run against both
providers
- Run black check for all python scripts
- Use initscripts as provider except when NetworkManager is running
- Rename network_provider_default to network_provider_os_default, since
it contains the default based on the OS
The "nm" provider talks to NetworkManager via libnm and python GObject
introspection. Install the required python library by default.
Unfortunately, it's not immediately clear whether we want to install
python2-gobject or python3-gobject. Yeay, python.
The role currently supports two providers: "nm" and "initscripts".
The provider is autodetected by loading one of the vars/*.yml files
(where the default is set via the internal "network_provider_default" variable).
The user can still overwrite the provider, by explicitly setting the
"network_provider" variable.
Depending on the provider there is the list of packages that shall be
installed and the service to start. Selecting this was broken before.
This is now fixed and works like following:
The variables "network_service_name" and "network_packages" can be
specified by the user as host variables. But usually the user wouldn't
want to do that. Instead, those settings depend on "network_provider".
The role looks into the internal "_network_provider_setup" dictionary,
which defaults to "network_service_name_nm", "network_service_name_initscripts",
"network_packages_nm", and "network_packages_initscripts".
These default variables are initialized in "defaults/main.yml" as well,
but they could be overwritten via "vars/*.yml" files, or via any other
mechanism.
https://github.com/linux-system-roles/network/pull/14https://bugzilla.redhat.com/show_bug.cgi?id=1485074
The role already supported a default variable ("network_provider") and
host variables ("network_provider_default", "network_service_name",
"network_packages").
Don't use nested variables under "network" like
network:
provider:
ignore_error:
connections:
instead promote them all to top-level variables like:
network_provider:
network_ignore_error:
network_connections:
This seems more consistent (as we already have multiple top-level
variables), it seems to follow ansible style, and it makes it easier
to overload individual variables via conditional include files.
