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
The states "up" and "down" previously would always change state. That
is, specifying them in the playbook will always invoke `ifup` (or
`ifdown`) or the corresponding of `nmcli connection up` (or `nmcli
connection down`).
That was intentional behavior, because the role doesn't really know which
profile is currently active. That is certainly the case for "initscripts",
where the role has almost no information about the current runtime
state. For "nm" provider, the role knows whether the connection is
already active. However, that alone also does not guarantee that the
current runtime state is idential to what would be the result of an
explicit `nmcli connection up`.
Hence, to be sure that the current state is always as expected, the role
would always explicitly issue the commands and report "changed=1".
That is quite harmful, because running the same role multiple times
should not report changes every time. Also, issuing `ifup` may behave
badly, if the interface is already configured.
Now, try to determine whether the desire "up" or "down" state is already
reached and do nothing.
For "nm" provider that is easy and quite safe. There is still the
possibility to trick the role into thinking that the right configuration
is active, when it actually is not. For example via `nmcli device
modify` on the host. But in general, it should work just fine.
Especially, if the admin manually modifies the runtime state, it may be
just desired for "state: up" not to change anything.
For "initscripts" this is much more fragile. There isn't really much
that can be done about it, because the role doesn't know what is currently
configured on the system.
There is also a new option "force_state_change" to restore the previous
behavior.
https://bugzilla.redhat.com/show_bug.cgi?id=1476053
The role targets NetworkManager 1.8.0 API or newer. Exposing the
active connection state was added in 1.8 API, hence the role failed
against older NetworkManager version.
While that is not officially supported, the workaround is simple,
so do it.
https://bugzilla.redhat.com/show_bug.cgi?id=1476053
We delete the connection asynchrnonously using libnm. Even after the
asynchronous request completes, the connection may still in the cache.
That is a bit odd, but maybe not a bug in libnm. Because it can happen
that the connection was active, so it takes time to bring it down.
Maybe the asynchronous request should not complete in libnm before
the connection is truly gone. But note that deactivating a connection
can take arbitrary long, so it's not clear that his would be the best
behavior.
Anyway, work around it by waiting.
The effect of this bug is if you have "state: absent" followed by
"state:up", then the intermediate "present" state will be skipped.
That is, because it appears that the connection still exists, although
it's about to be deleted. The subsequent "up" will then fail as the
connection is gone in the meantime.
https://github.com/linux-system-roles/network/issues/7https://bugzilla.redhat.com/show_bug.cgi?id=1478910
We group logging messages by their connection (@idx). Finally,
when constructing the overall result, reorder the messages
to ensure that their are still in chronological order.
Usually they are anyway, because we handle connections one-by-one,
and wouldn't log messages for previous connections.
We hack the "warnings" JSON result to return logging messages. However,
ansible will suppress duplicate warnings. That is inconvenient. Avoid that
by prefixing each logging message with an index.
This way one will be able to reliably detect when the example playbook was
forgotten to be upated with correct addresses, as the RFC 5737 addresses are
never used in production (the original RFC 1918 ones often are).
https://github.com/linux-system-roles/network/issues/5
