Like for 'bond' and 'ethernet', don't merge the vlan specific property
in the top-level. Instead, nest them under 'vlan'.
This duplicates and deprecates the existing 'vlan_id', but the old
parameter is still supported.
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.
Refactor the code, to make Cmd independent of ansible includes.
This would simplify to extend the library to run as stand-alone
application or to re-use parts without ansible.
Also, it better separates the code.
https://github.com/linux-system-roles/network/pull/23
run() supports a --check mode (DRY_RUN) and a real mode,
where the real mode consists of a PRE_RUN that only simulates
the steps and a REAL_RUN.
Actualy changes can only happen during REAL_RUN (and we pretend
that they happen during DRY_RUN).
Fix handling of the change flag, is was broken previously.
Also, we need to set the is-changed flag to True before actually
invoking the action. Because, if we fail, we might fail_json()
right away, and need to correct changed flag.
Now, that we only create the AnsibleUtil instance when we already
know that we run under ansible (not from unit tests), we can avoid
initializing the AnsibleModule lazily.
It works like 'route_append_only' and can be used to prevent
the role from deleting rule files. That makes especaily sense,
because the role currently doesn't support routing rules.
Also, NetworkManager still doesn't support routing rules either.
One day, the role (and maybe NetworkManager) will support rules,
and at that point it will start configuring them. That is the
reason why the new option already defaults to 'False'. Because,
once we add support for rules, we want the role to manage them
by default.
Depending on the provider, we have additional restrictions on the
input arguments. Validate them early.
Without this, we will only fail later when we want to get the
'interface_name' of a parent or a master profile. Fail early.
The major reason for this, is to expose this validation so that
it can be used by unit tests, to check whether proceeding will
lead to a known failure.
Addresses (currently) have only few properties, so this might
not make too much sense in the first moment. However, we will
add routes, which have lots of properties.
To support routes, we will treat them as dictionaries, not string
entries. Hence, for consistency, allow that syntax for addresses as
well.
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
