From ffa98f487654274137f8a9ed89df193ee5e23be1 Mon Sep 17 00:00:00 2001 From: Till Maas Date: Wed, 7 Apr 2021 10:58:19 +0200 Subject: [PATCH] Unify Markdown syntax - Use a consistent style for lists and fix indentations - Adjust whitespace to fence lists or code blocks - Remove double blank lines - Wrap lines at 88 characters - Add missing notations for code - Use proper links instead of plain URLs - Reword some parts to fit the style and update the text Signed-off-by: Till Maas --- CHANGELOG.md | 16 ++- README.md | 306 ++++++++++++++++++++++++++---------------------- contributing.md | 255 ++++++++++++++++++++-------------------- 3 files changed, 307 insertions(+), 270 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index a169247..159726b 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,18 +1,28 @@ -# Changelog -## [1.2.0] - 2020-08-26 +Changelog +========= + +[1.2.0] - 2020-08-26 +-------------------- + ### Changes + - Rename ethtool features to use underscores instead of dashes to support Jinja2 dot notation. Accept old notation for compatibility with existing playbooks. + ### New features + - Initial 802.1x authentication support (only EAP-TLS) - Wireless support - Handle OracleLinux as a RHEL clone - Remove dependency on ethtool command line tool - initscripts: Support creating and activating bond profiles in one run -- Ignore up/down states if a profile is not defined and not present on the managed host +- Ignore up/down states if a profile is not defined and not present on the + managed host - Document bond profiles + ### Bug fixes + - NetworkManager: Always rollback checkpoint on failure - NetworkManager: Try to reapply changes to reduce network interruptions - initscripts: Fix dependencies for Fedora 32 diff --git a/README.md b/README.md index 3106d8c..93ccc39 100644 --- a/README.md +++ b/README.md @@ -1,5 +1,6 @@ linux-system-roles/network ========================== + [![Coverage Status](https://coveralls.io/repos/github/linux-system-roles/network/badge.svg)](https://coveralls.io/github/linux-system-roles/network) ![CI Testing](https://github.com/linux-system-roles/network/workflows/tox/badge.svg) [![Code Style: black](https://img.shields.io/badge/code%20style-black-000000.svg)](https://github.com/ambv/black) @@ -23,6 +24,7 @@ This role can be used to configure: Introduction ------------ + The `network` role supports two providers: `nm` and `initscripts`. `nm` is used by default in RHEL7 and `initscripts` in RHEL6. These providers can be configured per host via the [`network_provider`](#provider) variable. In @@ -35,19 +37,20 @@ For `initscripts`, the legacy network service is required as used in Fedora or R For each host a list of networking profiles can be configured via the `network_connections` variable. -- For `initscripts`, profiles correspond to ifcfg files in the `/etc/sysconfig/network-scripts/ifcfg-*` directory. +- For `initscripts`, profiles correspond to ifcfg files in the + `/etc/sysconfig/network-scripts/ifcfg-*` directory. - For `NetworkManager`, profiles correspond to connection profiles as handled by NetworkManager. Fedora and RHEL use the `ifcfg-rh-plugin` for NetworkManager, which also writes or reads configuration files to `/etc/sysconfig/network-scripts/ifcfg-*` for compatibility. -Note that the `network` role primarily operates on networking profiles (connections) and -not on devices, but it uses the profile name by default as the interface name. -It is also possible to create generic profiles, by creating for example a -profile with a certain IP configuration without activating the profile. To -apply the configuration to the actual networking interface, use the `nmcli` -commands on the target system. +Note that the `network` role primarily operates on networking profiles +(connections) and not on devices, but it uses the profile name by default as +the interface name. It is also possible to create generic profiles, by creating +for example a profile with a certain IP configuration without activating the +profile. To apply the configuration to the actual networking interface, use the +`nmcli` commands on the target system. **Warning**: The `network` role updates or creates all connection profiles on the target system as specified in the `network_connections` variable. Therefore, @@ -57,21 +60,25 @@ Exceptions are mentioned below. Variables --------- -The `network` role is configured via variables starting with `network_` as the name prefix. -List of variables: -* `network_provider` - The `network_provider` variable allows to set a specific provider - (`nm` or `initscripts`) . Setting it to `{{ network_provider_os_default }}`, the - provider is set depending on the operating system. This is usually `nm` except for - RHEL 6 or CentOS 6 systems. Changing the provider for an existing profile is not - supported. To switch providers, it is recommended to first remove profiles with the - old provider and then create new profiles with the new provider. -* `network_connections` - The connection profiles are configured as `network_connections`, - which is a list of dictionaries that include specific options. -* `network_allow_restart` - Certain configurations require the role to restart network services. - For example, if a wireless connection is configured and NetworkManager-wifi is not installed, - NetworkManager must be restarted prior to the connection being configured. Setting this to - `no` will prevent the role from restarting network service. +The `network` role is configured via variables starting with `network_` as +the name prefix. List of variables: + +- `network_provider` - The `network_provider` variable allows to set a specific + provider (`nm` or `initscripts`) . Setting it to `{{ + network_provider_os_default }}`, the provider is set depending on the + operating system. This is usually `nm` except for RHEL 6 or CentOS 6 systems. + Changing the provider for an existing profile is not supported. To switch + providers, it is recommended to first remove profiles with the old provider + and then create new profiles with the new provider. +- `network_connections` - The connection profiles are configured as + `network_connections`, which is a list of dictionaries that include specific + options. +- `network_allow_restart` - Certain configurations require the role to restart + network services. For example, if a wireless connection is configured and + NetworkManager-wifi is not installed, NetworkManager must be restarted prior + to the connection being configured. Setting this to `no` will prevent the + role from restarting network service. Examples of Variables --------------------- @@ -88,8 +95,9 @@ network_allow_restart: yes Options ------- -The `network_connections` variable is a list of dictionaries that include the following options. -List of options: + +The `network_connections` variable is a list of dictionaries that include the +following options. List of options: ### `name` (required) @@ -100,38 +108,42 @@ Note that you can have multiple profiles for the same device, but only one profile can be active on the device each time. For NetworkManager, a connection can only be active at one device each time. -* For `NetworkManager`, the `name` option corresponds to the +- For `NetworkManager`, the `name` option corresponds to the [`connection.id`](https://developer.gnome.org/NetworkManager/stable/nm-settings.html#nm-settings.property.connection.id) property option. Although NetworkManager supports multiple connections with the same `connection.id`, the `network` role cannot handle a duplicate `name`. Specifying a `name` multiple times refers to the same connection profile. -* For `initscripts`, the `name` option determines the ifcfg file name `/etc/sysconfig/network-scripts/ifcfg-$NAME`. +- For `initscripts`, the `name` option determines the ifcfg file name `/etc/sysconfig/network-scripts/ifcfg-$NAME`. Note that the `name` does not specify the `DEVICE` but a filename. As a consequence, `'/'` is not a valid character for the `name`. -You can also use the same connection profile multiple times. Therefore, it is possible to create a profile and activate it separately. +You can also use the same connection profile multiple times. Therefore, it is possible +to create a profile and activate it separately. ### `state` -The `state` option identifies what is the runtime state of each connection profile. The `state` option (optional) can be set to the following values: +The `state` option identifies what is the runtime state of each connection profile. The +`state` option (optional) can be set to the following values: -* `up` - the connection profile is activated -* `down` - the connection profile is deactivated +- `up` - the connection profile is activated +- `down` - the connection profile is deactivated #### `state: up` + - For `NetworkManager`, this corresponds to `nmcli connection id {{name}} up`. - For `initscripts`, this corresponds to `ifup {{name}}`. When the `state` option is set to `up`, you can also specify the `wait` option (optional): -* `wait: 0` - initiates only the activation, but does not wait until the device is fully connected. -The connection will be completed in the background, for example after a DHCP lease was received. -* `wait: ` is a timeout that enables you to decide how long you give the device to -activate. The default is using a suitable timeout. Note that the `wait` option is -only supported by NetworkManager. +- `wait: 0` - initiates only the activation, but does not wait until the device is fully + connected. The connection will be completed in the background, for example after a + DHCP lease was received. +- `wait: ` is a timeout that enables you to decide how long you give the device + to activate. The default is using a suitable timeout. Note that the `wait` option is + only supported by NetworkManager. Note that `state: up` always re-activates the profile and possibly changes the networking configuration, even if the profile was already active before. As @@ -143,14 +155,16 @@ a consequence, `state: up` always changes the system. - For `initscripts`, it corresponds to call `ifdown {{name}}`. -You can deactivate a connection profile, even if is currently not active. As a consequence, `state: down` always changes the system. - -Note that if the `state` option is unset, the connection profile’s runtime state will not be changed. +You can deactivate a connection profile, even if is currently not active. As a +consequence, `state: down` always changes the system. +Note that if the `state` option is unset, the connection profile’s runtime state will +not be changed. ### `persistent_state` -The `persistent_state` option identifies if a connection profile is persistent (saved on disk). The `persistent_state` option can be set to the following values: +The `persistent_state` option identifies if a connection profile is persistent (saved on +disk). The `persistent_state` option can be set to the following values: #### `persistent_state: present` (default) @@ -169,30 +183,31 @@ profile on a currently disconnected device. ([rh#1401515](https://bugzilla.redha The `absent` value ensures that the profile is not present on the target host. If a profile with the given `name` exists, it will be deleted. In this case: -- `NetworkManager` deletes all connection profiles with the corresponding `connection.id`. - Deleting a profile usually does not change the current networking configuration, unless - the profile was currently activated on a device. Deleting the currently - active connection profile disconnects the device. That makes the device eligible - to autoconnect another connection (for more details, see [rh#1401515](https://bugzilla.redhat.com/show_bug.cgi?id=1401515)). +- `NetworkManager` deletes all connection profiles with the corresponding + `connection.id`. Deleting a profile usually does not change the current networking + configuration, unless the profile was currently activated on a device. Deleting the + currently active connection profile disconnects the device. That makes the device + eligible to autoconnect another connection (for more details, see + [rh#1401515](https://bugzilla.redhat.com/show_bug.cgi?id=1401515)). -- `initscripts` deletes the ifcfg file in most cases with no impact on the runtime state of the system unless some component is watching the sysconfig directory. +- `initscripts` deletes the ifcfg file in most cases with no impact on the runtime state + of the system unless some component is watching the sysconfig directory. **Note**: For profiles that only contain a `state` option, the `network` role only activates or deactivates the connection without changing its configuration. - ### `type` The `type` option can be set to the following values: - - `ethernet` - - `bridge` - - `bond` - - `team` - - `vlan` - - `macvlan` - - `infiniband` - - `wireless` +- `ethernet` +- `bridge` +- `bond` +- `team` +- `vlan` +- `macvlan` +- `infiniband` +- `wireless` #### `type: ethernet` @@ -200,17 +215,20 @@ If the type is `ethernet`, then there can be an extra `ethernet` dictionary with items (options): `autoneg`, `speed` and `duplex`, which correspond to the settings of the `ethtool` utility with the same name. -* `autoneg`: `yes` (default) or `no` [if auto-negotiation is enabled or disabled] -* `speed`: speed in Mbit/s -* `duplex`: `half` or `full` +- `autoneg`: `yes` (default) or `no` [if auto-negotiation is enabled or disabled] +- `speed`: speed in Mbit/s +- `duplex`: `half` or `full` -Note that the `speed` and `duplex` link settings are required when autonegotiation is disabled (autoneg:no). +Note that the `speed` and `duplex` link settings are required when autonegotiation is +disabled (`autoneg: no`). #### `type: bridge`, `type: bond`, `type: team` -The `bridge`, `bond`, `team` device types work similar. Note that `team` is not supported in RHEL6 kernels. +The `bridge`, `bond`, `team` device types work similar. Note that `team` is not +supported in RHEL6 kernels. -For ports, the `port_type` and `controller` properties must be set. Note that ports should not have `ip` settings. +For ports, the `port_type` and `controller` properties must be set. Note that ports +should not have `ip` settings. The `controller` refers to the `name` of a profile in the Ansible playbook. It is neither an interface-name nor a connection-id of @@ -224,11 +242,13 @@ NetworkManager. As `controller` refers to other profiles of the same or another play, the order of the `connections` list matters. Profiles that are referenced by other profiles need to be -specified first. Also, `--check` ignores the value of the `controller` and assumes it will -be present during a real run. That means, in presence of an invalid `controller`, `--check` -may signal success but the actual play run fails. +specified first. Also, `--check` ignores the value of the `controller` and assumes it +will be present during a real run. That means, in presence of an invalid `controller`, +`--check` may signal success but the actual play run fails. + +The `team` type uses `roundrobin` as the `runner` configuration. No further +configuration is supported at the moment. -The `team` type uses `roundrobin` as the `runner` configuration. No further configuration is supported at the moment. #### `type: vlan` Similar to `controller`, the `parent` references the connection profile in the ansible @@ -236,22 +256,24 @@ role. #### `type: macvlan` -Similar to `controller` and `vlan`, the `parent` references the connection profile in the ansible -role. +Similar to `controller` and `vlan`, the `parent` references the connection profile in +the ansible role. #### `type: wireless` -The `wireless` type supports WPA-PSK (password) authentication and WPA-EAP (802.1x) authentication. +The `wireless` type supports WPA-PSK (password) authentication and WPA-EAP (802.1x) +authentication. `nm` (NetworkManager) is the only supported `network_provider` for this type. -If WPA-EAP is used, ieee802_1x settings must be defined in the [ieee802_1x](#-`ieee802_1x`) option. +If WPA-EAP is used, ieee802_1x settings must be defined in the +[ieee802_1x](#-`ieee802_1x`) option. The following options are supported: -* `ssid`: the SSID of the wireless network (required) -* `key_mgmt`: `wpa-psk` or `wpa-eap` (required) -* `password`: password for the network (required if `wpa-psk` is used) +- `ssid`: the SSID of the wireless network (required) +- `key_mgmt`: `wpa-psk` or `wpa-eap` (required) +- `password`: password for the network (required if `wpa-psk` is used) ### `autoconnect` @@ -280,11 +302,10 @@ maximum value of the `mtu` option depends on the underlying device. ### `interface_name` -For the `ethernet` and `infiniband` types, the `interface_name` option restricts the profile to -the given interface by name. This argument is optional and by default the -profile name is used unless a mac address is specified using the `mac` key. -Specifying an empty string (`""`) means that the profile is not -restricted to a network interface. +For the `ethernet` and `infiniband` types, the `interface_name` option restricts the +profile to the given interface by name. This argument is optional and by default the +profile name is used unless a mac address is specified using the `mac` key. Specifying +an empty string (`""`) means that the profile is not restricted to a network interface. **Note:** With [persistent interface naming](https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/ch-Consistent_Network_Device_Naming.html), the interface is predictable based on the hardware configuration. @@ -302,16 +323,15 @@ The `zone` option sets the firewalld zone for the interface. Ports to the bridge, bond or team devices cannot specify a zone. - ### `ip` The IP configuration supports the following options: -* `address` +- `address` Manual addressing can be specified via a list of addresses under the `address` option. -* `dhcp4`, `auto6`, and `ipv6_disabled` +- `dhcp4`, `auto6`, and `ipv6_disabled` Also, manual addressing can be specified by setting either `dhcp4` or `auto6`. The `dhcp4` key is for DHCPv4 and `auto6` for StateLess Address Auto Configuration @@ -319,7 +339,7 @@ The IP configuration supports the following options: depends on the presence of manual addresses. `ipv6_disabled` can be set to disable ipv6 for the connection. -* `dhcp4_send_hostname` +- `dhcp4_send_hostname` If `dhcp4` is enabled, it can be configured whether the DHCPv4 request includes the hostname via the `dhcp4_send_hostname` option. Note that `dhcp4_send_hostname` @@ -327,17 +347,17 @@ The IP configuration supports the following options: [`ipv4.dhcp-send-hostname`](https://developer.gnome.org/NetworkManager/stable/nm-settings.html#nm-settings.property.ipv4.dhcp-send-hostname) property. -* `dns` +- `dns` Manual DNS configuration can be specified via a list of addresses given in the `dns` option. -* `dns_search` +- `dns_search` `dns_search` is only supported for IPv4 nameservers. Manual DNS configuration can be specified via a list of domains to search given in the `dns_search` option. -* `dns_options` +- `dns_options` `dns_options` is only supported for the NetworkManager provider and IPv4 nameservers. Manual DNS configuration via a list of DNS options can be given in the @@ -358,43 +378,47 @@ The IP configuration supports the following options: - `trust-ad` - `use-vc` -**Note:** The "trust-ad" setting is only honored if the profile contributes name + **Note:** The "trust-ad" setting is only honored if the profile contributes name servers to resolv.conf, and if all contributing profiles have "trust-ad" enabled. When using a caching DNS plugin (dnsmasq or systemd-resolved in NetworkManager.conf) then "edns0" and "trust-ad" are automatically added. +- `route_metric4` and `route_metric6` -* `route_metric4` and `route_metric6` - - - For `NetworkManager`, `route_metric4` and `route_metric6` corresponds to the - [`ipv4.route-metric`](https://developer.gnome.org/NetworkManager/stable/nm-settings.html#nm-settings.property.ipv4.route-metric) and + For `NetworkManager`, `route_metric4` and `route_metric6` corresponds to the + [`ipv4.route-metric`](https://developer.gnome.org/NetworkManager/stable/nm-settings.html#nm-settings.property.ipv4.route-metric) + and [`ipv6.route-metric`](https://developer.gnome.org/NetworkManager/stable/nm-settings.html#nm-settings.property.ipv6.route-metric) properties, respectively. If specified, it determines the route metric for DHCP - assigned routes and the default route, and thus the priority for multiple interfaces. + assigned routes and the default route, and thus the priority for multiple + interfaces. -* `route` +- `route` - Static route configuration can be specified via a list of routes given in the `route` - option. The default value is an empty list. Each route is a dictionary with the following - entries: `network`, `prefix`, `gateway` and `metric`. `network` and `prefix` specify - the destination network. - Note that Classless inter-domain routing (CIDR) notation or network mask notation are not supported yet. + Static route configuration can be specified via a list of routes given in the + `route` option. The default value is an empty list. Each route is a dictionary with + the following entries: `network`, `prefix`, `gateway` and `metric`. `network` and + `prefix` specify the destination network. + Note that Classless inter-domain routing (CIDR) notation or network mask notation + are not supported yet. -* `route_append_only` +- `route_append_only` The `route_append_only` option allows only to add new routes to the existing routes on the system. - If the `route_append_only` boolean option is set to `yes`, the specified routes are appended to the existing routes. - If `route_append_only` is set to `no` (default), the current routes are replaced. - Note that setting `route_append_only` to `yes` without setting `route` has the effect of preserving the current static routes. + If the `route_append_only` boolean option is set to `yes`, the specified routes are + appended to the existing routes. If `route_append_only` is set to `no` (default), + the current routes are replaced. Note that setting `route_append_only` to `yes` + without setting `route` has the effect of preserving the current static routes. -* `rule_append_only` +- `rule_append_only` The `rule_append_only` boolean option allows to preserve the current routing rules. Note that specifying routing rules is not supported yet. -**Note:** When `route_append_only` or `rule_append_only` is not specified, the `network` role deletes the current routes or routing rules. +**Note:** When `route_append_only` or `rule_append_only` is not specified, the network +role deletes the current routes or routing rules. **Note:** Ports to the bridge, bond or team devices cannot specify `ip` settings. @@ -488,29 +512,31 @@ kernel and device, changing some options might not be supported. Configures 802.1x authentication for an interface. -Currently, NetworkManager is the only supported provider and EAP-TLS is the only supported EAP method. +Currently, NetworkManager is the only supported provider and EAP-TLS is the only +supported EAP method. SSL certificates and keys must be deployed on the host prior to running the role. -* `eap` +- `eap` The allowed EAP method to be used when authenticating to the network with 802.1x. Currently, `tls` is the default and the only accepted value. -* `identity` (required) +- `identity` (required) Identity string for EAP authentication methods. -* `private_key` (required) +- `private_key` (required) - Absolute path to the client's PEM or PKCS#12 encoded private key used for 802.1x authentication. + Absolute path to the client's PEM or PKCS#12 encoded private key used for 802.1x + authentication. - * `private_key_password` +- `private_key_password` Password to the private key specified in `private_key`. - * `private_key_password_flags` +- `private_key_password_flags` List of flags to configure how the private key password is managed. @@ -522,43 +548,48 @@ SSL certificates and keys must be deployed on the host prior to running the role - `not-saved` - `not-required` - See NetworkManager documentation on "Secret flag types" more details (`man 5 nm-settings`). + See NetworkManager documentation on "Secret flag types" more details (`man 5 + nm-settings`). - * `client_cert` (required) +- `client_cert` (required) - Absolute path to the client's PEM encoded certificate used for 802.1x authentication. + Absolute path to the client's PEM encoded certificate used for 802.1x + authentication. - * `ca_cert` +- `ca_cert` - Absolute path to the PEM encoded certificate authority used to verify the EAP server. + Absolute path to the PEM encoded certificate authority used to verify the EAP + server. - * `ca_path` +- `ca_path` Absolute path to directory containing additional pem encoded ca certificates used to verify the EAP server. Can be used instead of or in addition to ca_cert. Cannot be used if system_ca_certs is enabled. - * `system_ca_certs` +- `system_ca_certs` - If set to `True`, NetworkManager will use the system's trusted ca certificates to verify the EAP server. + If set to `True`, NetworkManager will use the system's trusted ca + certificates to verify the EAP server. - * `domain_suffix_match` +- `domain_suffix_match` - If set, NetworkManager will ensure the domain name of the EAP server certificate matches this string. + If set, NetworkManager will ensure the domain name of the EAP server certificate + matches this string. ### `bond` The `bond` setting configures the options of bonded interfaces (type `bond`). It supports the following options: - * `mode` +- `mode` - Bonding mode. See the - [kernel documentation](https://www.kernel.org/doc/Documentation/networking/bonding.txt) - or your distribution `nmcli` documentation for valid values. - NetworkManager defaults to `balance-rr`. + Bonding mode. See the + [kernel documentation](https://www.kernel.org/doc/Documentation/networking/bonding.txt) + or your distribution `nmcli` documentation for valid values. + NetworkManager defaults to `balance-rr`. - * `miimon` +- `miimon` Sets the MII link monitoring interval (in milliseconds) @@ -638,7 +669,6 @@ network_connections: #interface_name: br0 # defaults to the connection name ``` - Configuring a bridge connection: ```yaml @@ -797,7 +827,6 @@ The `network` role rejects invalid configurations. It is recommended to test the with `--check` first. There is no protection against wrong (but valid) configuration. Double-check your configuration before applying it. - Compatibility ------------- @@ -823,13 +852,15 @@ after disabling the NetworkManager service. Limitations ----------- -As Ansible usually works via the network, for example via SSH, there are some limitations to be considered: +As Ansible usually works via the network, for example via SSH, there are some +limitations to be considered: -The `network` role does not support bootstraping networking configuration. One -option may be [ansible-pull](https://docs.ansible.com/ansible/playbooks_intro.html#ansible-pull). -Another option maybe be to initially auto-configure the host during installation -(ISO based, kickstart, etc.), so that the host is connected to a management LAN -or VLAN. It strongly depends on your environment. +The `network` role does not support bootstraping networking configuration. One option +may be +[ansible-pull](https://docs.ansible.com/ansible/playbooks_intro.html#ansible-pull). +Another option maybe be to initially auto-configure the host during installation (ISO +based, kickstart, etc.), so that the host is connected to a management LAN or VLAN. It +strongly depends on your environment. For `initscripts` provider, deploying a profile merely means to create the ifcfg files. Nothing happens automatically until the play issues `ifup` or `ifdown` @@ -845,12 +876,12 @@ down and possibly removes virtual interfaces. With the `initscripts` provider removing a profile does not change its current runtime state (this is a future feature for NetworkManager as well). -For NetworkManager, modifying a connection with autoconnect enabled -may result in the activation of a new profile on a previously disconnected -interface. Also, deleting a NetworkManager connection that is currently active -results in removing the interface. Therefore, the order of the steps should be -followed, and carefully handling of [autoconnect](#autoconnect) property may be -necessary. This should be improved in NetworkManager RFE [rh#1401515](https://bugzilla.redhat.com/show_bug.cgi?id=1401515). +For NetworkManager, modifying a connection with autoconnect enabled may result in the +activation of a new profile on a previously disconnected interface. Also, deleting a +NetworkManager connection that is currently active results in removing the interface. +Therefore, the order of the steps should be followed, and carefully handling of +[autoconnect](#autoconnect) property may be necessary. This should be improved in +NetworkManager RFE [rh#1401515](https://bugzilla.redhat.com/show_bug.cgi?id=1401515). It seems difficult to change networking of the target host in a way that breaks the current SSH connection of ansible. If you want to do that, ansible-pull might @@ -876,6 +907,5 @@ connectivity due to an error, NetworkManager would automatically rollback after timeout. The limitations is that this would only work with NetworkManager, and it is not clear that rollback will result in a working configuration. - *Want to contribute? Take a look at our [contributing guidelines](https://github.com/linux-system-roles/network/blob/main/contributing.md)!* diff --git a/contributing.md b/contributing.md index 035a975..cb8f14f 100644 --- a/contributing.md +++ b/contributing.md @@ -1,6 +1,8 @@ -# Contributing to the Network Linux System Role +Contributing to the Network Linux System Role +============================================= -## Where to start +Where to start +-------------- - **Bugs and needed implementations** are listed on [Github Issues](https://github.com/linux-system-roles/network/issues). Issues labeled with @@ -14,7 +16,8 @@ Requests](https://help.github.com/en/github/collaborating-with-issues-and-pull-r - The code needs to be **compatible with Python 2.6, 2.7, 3.6, 3.7 and 3.8**. -## Code structure +Code structure +-------------- The repository is structured as follows: @@ -36,26 +39,26 @@ The repository is structured as follows: - `./tests/playbooks/` - Contains the complete tests for the role. `./tests/test_*.yml` are shims to run tests once for every provider. `./tests/tasks/` contains task - snippets that are used in multiple tests to avoid having the same code repeated + snippets that are used in multiple tests to avoid having the same code repeated multiple times. The rest of files in the root folder mostly serve as configuration files for diferent testing tools and bots that help with the manteinance of the project. - The code files will always have the imports on the first place, followed by constants and in the last place, classes and methods. The style of python coding for this project is [**PEP 8**](https://www.python.org/dev/peps/pep-0008/), with automatic formatting thanks to [Python Black](https://black.readthedocs.io/en/stable/). Make sure to install the formatter, it will help you a lot throughout the whole coding process! -## Configuring Git +Configuring Git +--------------- Before starting to contribute, make sure you have the basic git configuration: Your name and email. This will be useful when signing your contributions. The following commands will set your global name and email, althought you can change it later for every repo: -``` +```bash git config --global user.name "Jane Doe" git config --global user.email janedoe@example.com ``` @@ -63,14 +66,15 @@ git config --global user.email janedoe@example.com The git editor is your system's default. If you feel more comfortable with a different editor for writing your commits (such as Vim), change it with: -``` +```bash git config --global core.editor vim ``` -If you want to check your settings, use `git config --list` to see all the settings Git can find. +If you want to check your settings, use `git config --list` to see all the settings Git +can find. - -## How to contribute +How to contribute +----------------- 1. Make a [fork](https://help.github.com/en/github/getting-started-with-github/fork-a-repo) @@ -80,30 +84,34 @@ of this repository. changes you need to complete an issue. 3. Do not forget to run unit and integration tests before pushing any changes! + 1. This project uses [tox](https://tox.readthedocs.io/en/latest/) to run unit tests. + You can try it with `tox -e py36` in case you want to try it using Python 3.6, or + just `tox` if you want to run all the tests. - - This project uses [tox](https://tox.readthedocs.io/en/latest/) to run unit tests. - You can try it with `tox -e py36` in case you want to try it using Python 3.6, or - just `tox` if you want to run all the tests. + 2. Check the formatting of the code with + [Python Black](https://black.readthedocs.io/en/stable/) - - Check the formatting of the code with [Python Black](https://black.readthedocs.io/en/stable/) + 3. Check the YAML files are correctly formatted using `tox -e yamllint`. - - Check the YAML files are correctly formatted using `tox -e yamllint`. + 4. Integration tests are executed as + [Ansible Playbooks](https://docs.ansible.com/ansible/latest/user_guide/playbooks.html). - - Integration tests are executed as - [ansible-playbooks](https://docs.ansible.com/ansible/latest/user_guide/playbooks.html). + To run them you can use a cloud image like the [CentOS Linux 8.1 + VM](https://cloud.centos.org/centos/8/x86_64/images/CentOS-8-GenericCloud-8.1.1911-20200113.3.x86_64.qcow2) + and execute the command and download the package + `standard-test-roles-inventory-qemu` from the Fedora repository: -To run them you can use a cloud image like the [CentOS 8.1 -VM](https://cloud.centos.org/centos/8/x86_64/images/CentOS-8-GenericCloud-8.1.1911-20200113.3.x86_64.qcow2) -and execute the command and download the package -`standard-test-roles-inventory-qemu` from the Fedora repository: + ```bash + dnf install standard-test-roles-inventory-qemu + ``` -```dnf install standard-test-roles-inventory-qemu``` + Note that the last path is the one of the test you want to run: -Note that the last path is the one of the test you want to run: - -`TEST_SUBJECTS=CentOS-8-GenericCloud-8.1.1911-20200113.3.x86_64.qcow2 -ansible-playbook -v -i /usr/share/ansible/inventory/standard-inventory-qcow2 -tests/test_default.yml` + ```bash + TEST_SUBJECTS=CentOS-8-GenericCloud-8.1.1911-20200113.3.x86_64.qcow2 \ + ansible-playbook -v -i /usr/share/ansible/inventory/standard-inventory-qcow2 \ + tests/test_default.yml + ``` 4. Once the work is ready and commited, push the branch to your remote fork and click on "new Pull Request" on Github. @@ -113,29 +121,28 @@ tests/test_default.yml` will merge it to the main project. ### Find other images for testing -To use the CentOS 6, CentOS 7, CentOS 8 images, please checkout the link below:
-https://cloud.centos.org/centos/6/images/CentOS-6-x86_64-GenericCloud-1907.qcow2c
-https://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud-2003.qcow2c
-https://cloud.centos.org/centos/8/x86_64/images/CentOS-8-GenericCloud-8.1.1911-20200113.3.x86_64.qcow2 -- `/6/images/` stands for CentOS 6 images, we can also change it to `/7/images/` to use -CentOS 7 images, change it to `/8/images/` to use CentOS 8 images. +The CentOS project publishes cloud images for +[CentOS Linux 6](https://cloud.centos.org/centos/6/images/), +[CentOS Linux 7](https://cloud.centos.org/centos/7/images/) and +[CentOS Linux 8](https://cloud.centos.org/centos/8/x86_64/images/). + - For qemu testing cases, we prefer the image architecture to be `x86_64-GenericCloud`. - `2003` in `CentOS-7-x86_64-GenericCloud-2003.qcow2c` stands for image released in -March 2020. + March 2020. - We can use the image with extension `.qcow2` and `.qcow2c`. - To save the image, right click on the link above, then select "Save link as...". -For Fedora, we recommend to use the latest qcow2 images from
-https://kojipkgs.fedoraproject.org/compose/cloud/ +For Fedora, we recommend to use the [latest qcow2 +images](https://kojipkgs.fedoraproject.org/compose/cloud/). ### Some important tips - Make sure your fork and branch are up-to-date with the main project. First of all, [configure a remote upstream for your fork](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/configuring-a-remote-for-a-fork), -and keep your branch up-to-date with the upstream using ```git pull --rebase upstream -main``` +and keep your branch up-to-date with the upstream using +`git pull --rebase upstream main`. - Try to make a commit per issue. @@ -157,49 +164,50 @@ added, and merge both file versions into one that combines it all. ### Naming Ansible Items -* All YAML or Python files, variables, arguments, repositories, and other such names +- All YAML or Python files, variables, arguments, repositories, and other such names should follow standard Python naming conventions of being in `snake_case_naming_schemes`. -* Names should be mnemonic and descriptive and not strive to shorten more than +- Names should be mnemonic and descriptive and not strive to shorten more than necessary. Systems support long identifier names, so use them to be descriptive -* All defaults and all arguments to a role should have a name that begins with the role +- All defaults and all arguments to a role should have a name that begins with the role name to help avoid collision with other names. Avoid names like `packages` in favor of a name like `network_packages`. -* Same argument applies for modules provided in the roles, they also need a `$ROLENAME_` +- Same argument applies for modules provided in the roles, they also need a `$ROLENAME_` prefix: `network_module`. While they are usually implementation details and not intended for direct use in playbooks, the unfortunate fact is that importing a role makes them available to the rest of the playbook and therefore creates opportunities for name collisions. -* Moreover, internal variables (those that are not expected to be set by users) are to +- Moreover, internal variables (those that are not expected to be set by users) are to be prefixed by two underscores: `__network_variable`. This includes variables set by - set_fact and register, because they persist in the namespace after the role has + `set_fact` and `register`, because they persist in the namespace after the role has finished! -* Do not use special characters other than underscore in variable names, even if +- Do not use special characters other than underscore in variable names, even if YAML/JSON allow them. (Using such variables in Jinja2 or Python would be then very confusing and probably not functional.) *Find more explanation on this matter in the [meta standards](https://github.com/oasis-roles/meta_standards#naming-things).* - ### Write a good commit message + Here are a few rules to keep in mind while writing a commit message - 1. Separate subject from body with a blank line - 2. Limit the subject line to 50 characters - 3. Capitalize the subject line - 4. Do not end the subject line with a period - 5. Use the imperative mood in the subject line - 6. Wrap the body at 72 characters - 7. Use the body to explain what and why vs. how +1. Separate subject from body with a blank line +2. Limit the subject line to 50 characters +3. Capitalize the subject line +4. Do not end the subject line with a period +5. Use the imperative mood in the subject line +6. Wrap the body at 72 characters +7. Use the body to explain what and why vs. how - A good commit message looks something like this -``` + A good commit message looks something like this: + +```text Summarize changes in around 50 characters or less More detailed explanatory text, if necessary. Wrap it to about 72 @@ -229,29 +237,27 @@ Here are a few rules to keep in mind while writing a commit message See also: #456, #789 Do not forget to sign your commit! Use `git commit -s` - ``` This is taken from [chris beams git commit](https://chris.beams.io/posts/git-commit/). You may want to read this for a more detailed explanation (and links to other posts on -how to write a good commit message). This content is licensed under +how to write a good commit message). This content is licensed under [CC-BY-SA](https://creativecommons.org/licenses/by-sa/4.0/). -### Sign off your commit. +### Sign off your commit -You need to sign off your commit. By adding your 'Signed-off-by' -line to the commit messages you adhere to the [Developer -Certificate of Origin (DCO)](https://developercertificate.org/). +You need to sign off your commit. By adding your 'Signed-off-by' line to the commit +messages you adhere to the +[Developer Certificate of Origin (DCO)](https://developercertificate.org/). -Use the `-s` command-line option to append the `Signed-off-by` -line when committing your code: +Use the `-s` command-line option to append the `Signed-off-by` line when committing your +code: `$ git commit -s` +This is the full text of the Developer Certificate of Origin: -This is the full text of the DCO: - -``` +```text Developer Certificate of Origin Version 1.1 @@ -291,12 +297,11 @@ By making a contribution to this project, I certify that: this project or the open source license(s) involved. ``` - ### Debugging When using the `nm` provider, NetworkManager create a checkpoint and reverts the changes on failures. This makes it hard to debug the error. To disable this, set the Ansible -variable `__network_debug_flags to include the value `disable-checkpoints`. Also tests +variable `__network_debug_flags` to include the value `disable-checkpoints`. Also tests clean up by default in case there are failures. They should be tagged as `tests::cleanup` and can be skipped. To use both, run the test playbooks like this: @@ -307,77 +312,68 @@ ansible-playbook --skip-tags tests::cleanup \ ``` ### NetworkManager Documentation -- [NM 1.0](https://lazka.github.io/pgi-docs/#NM-1.0), it contains full explanation about NetworkManager API, including but not limited to: - - Functions - - Callbacks - - Interfaces - - Classes - - Hierarchy - - Structures - - Class Structures - - Interface Structures - - Flags - - Enums - - Constants - - Symbol Mapping + +- [NM 1.0](https://lazka.github.io/pgi-docs/#NM-1.0), it contains a full explanation + about the NetworkManager API. ### Integration tests with podman + 1. Create `~/.ansible/collections/ansible_collections/containers/podman/` if this -directory does not exist and `cd` into this directory. -```bash -mkdir -p ~/.ansible/collections/ansible_collections/containers/podman/ -cd ~/.ansible/collections/ansible_collections/containers/podman/ -``` + directory does not exist and `cd` into this directory. + + ```bash + mkdir -p ~/.ansible/collections/ansible_collections/containers/podman/ + cd ~/.ansible/collections/ansible_collections/containers/podman/ + ``` 2. Clone the collection plugins for Ansible-Podman into the current directory. -```bash -git clone https://github.com/containers/ansible-podman-collections.git . -``` -3. Change directory into the `network/tests`, `network` is the Repo you cloned from -your local fork. -```bash -cd ~/network/tests -``` + ```bash + git clone https://github.com/containers/ansible-podman-collections.git . + ``` +3. Change directory into the `tests` subdirectory. + + ```bash + cd ~/network/tests + ``` 4. Use podman with `-d` to run in the background (daemon). Use `c7` because -`centos/systemd` is centos7. -```bash -podman run --name c7 --rm --privileged -v /sys/fs/cgroup:/sys/fs/cgroup:ro -d registry.centos.org/centos/systemd -``` + `centos/systemd` is centos7. + + ```bash + podman run --name lsr-ci-c7 --rm --privileged -v /sys/fs/cgroup:/sys/fs/cgroup:ro \ + -d registry.centos.org/centos/systemd + ``` 5. Use `podman unshare` first to run "podman mount" in root mode, use `-vi` to run -ansible as inventory in verbose mode, use `-c podman` to use collection plugins. Note, -the following tests are currently not working with podman: -- `tests_802_1x_nm.yml` -- `tests_802_1x_updated_nm.yml` -- `tests_bond_initscripts.yml` -- `tests_bond_nm.yml` -- `tests_bridge_initscripts.yml` -- `tests_bridge_nm.yml` -- `tests_default_nm.yml` -- `tests_ethernet_nm.yml` -- `tests_reapply_nm.yml` -- `tests_states_nm.yml` -- `tests_vlan_mtu_initscripts.yml` -- `tests_vlan_mtu_nm.yml` -- `tests_wireless_nm.yml` + ansible as inventory in verbose mode, use `-c podman` to use collection plugins. Note, + the following tests are currently not working with podman: + - `tests_802_1x_nm.yml` + - `tests_802_1x_updated_nm.yml` + - `tests_bond_initscripts.yml` + - `tests_bond_nm.yml` + - `tests_bridge_initscripts.yml` + - `tests_bridge_nm.yml` + - `tests_default_nm.yml` + - `tests_ethernet_nm.yml` + - `tests_reapply_nm.yml` + - `tests_states_nm.yml` + - `tests_vlan_mtu_initscripts.yml` + - `tests_vlan_mtu_nm.yml` + - `tests_wireless_nm.yml` -```bash -podman unshare -ansible-playbook -vi c7, -c podman tests_provider_nm.yml -``` + ```bash + podman unshare + ansible-playbook -vi lsr-ci-c7, -c podman tests_provider_nm.yml + ``` 6. NOTE that this leaves the container running in the background, to kill it: -```bash -> podman ps -CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES -02a45f9d53df registry.centos.org/centos/systemd:latest /usr/sbin/init 13 minutes ago Up 13 minutes ago c7 -> podman stop 02a45f9d53df -> podman rm 02a45f9d53df -``` + ```bash + podman stop lsr-ci-c7 + podman rm lsr-ci-c7 + ``` ### Continuous integration @@ -392,17 +388,18 @@ comment. The available commands are: - [citest bad] - Trigger a re-test for all machines with an error or failure status. - [citest pending] - Trigger a re-test for all machines with a pending status. - [citest commit:] - Whitelist a commit to be tested if the submitter is not -trusted. + trusted. + +How to reach us +--------------- -## How to reach us The mailing list for developers: systemroles@lists.fedorahosted.org [Subscribe to the mailing list](https://lists.fedorahosted.org/admin/lists/systemroles.lists.fedorahosted.org/) [Archive of the mailing list](https://lists.fedorahosted.org/archives/list/systemroles@lists.fedorahosted.org/) -If you are using IRC, join the `#systemroles` IRC channel on +If you are using IRC, join the `#systemroles` IRC channel on [freenode](https://freenode.net/kb/answer/chat) - *Thanks for contributing and happy coding!!*