The details of the issue is described in this ansible issue:
https://github.com/ansible/ansible/issues/68361
The workaround contains 2 changes.
1) Advice from @sivel:
replacing, e.g.,
from ansible.module_utils.network_lsr.nm.provider import NetworkManagerProvider
with
from ansible.module_utils.network_lsr.nm import provider
and then use provider.NetworkManagerProvider
2) In the later module_utils path finding path, gi.require_version("NM", "1.0")
in module_utils/network_lsr/nm/client.py fails with "ValueError: Namespace
NM not available" on the control node. By ignoring the exception, the failure
is worked around. Please note that the missing package issue never occurs
on the managed nodes since in case of "nm", the NetworkManager package is
installed in the network role.
Signed-off-by: Noriko Hosoi <nhosoi@redhat.com>
When deactivating a profile in libNM, we should:
* Check `NM.ActionConnection` existence
* Check `NM.ActionConnection.props.state` not DEACTIVATED
* Use signal `state-changed` of `NM.ActionConnection`.
* Only invoke `NM.Client.deactivate_connection_async()` if not
in DEACTIVATING state.
* Ignore `NM.ManagerError.CONNECTIONNOTACTIVE` error.
This patch also introduced a new class `NetworkManagerProvider`
in `module_utils/network_lsr/nm`:
* Independent from Ansible but need to use absolute import due to
limitation of ansible 2.8.
* Provide sync function wrapping async calls of libNM.
* Use stable logging method of python.
* Only load this module when provider is nm.
This patch also changed how logging is handling in
`Cmd_nm.run_action_down()` as initial step on isolate ansible log
mechanism from provider module.
By moving provider codes to `module_utils` folder, we can eventually
simplify the bloated `library/network_connections.py`.
Signed-off-by: Gris Ge <fge@redhat.com>
