community.general
community.general copied to clipboard
ansible-collections
nmcli module has unwelcoming language
Summary
community.general.nmcli uses terminology (ie, bridge-slave') that the Ansible community has committed to removing in Ansible code and collections. These terms come from upstream nmcli, but we should still consider if there's anything we can do to provide alternatives to users.
Since Network Manager is a project that Red Hat is actively involved in we can also reach out to other Red Hat folks to ask if there's any discussion or roadmap for these terms to be evaluated in the upstream.
Issue Type
Documentation Report
Component Name
nmcli
Ansible Version
$ ansible --version
Configuration
$ ansible-config dump --only-changed
OS / Environment
No response
Additional Information
No response
Code of Conduct
- [X] I agree to follow the Ansible Code of Conduct
In the D&I working group meeting we took an action to raise this with the internal Red Hat conscious language group
I don't think anything can be done here at the moment, you should really bring this issue up with the maintainers of NetworkManager/nmcli since this module relies on it and its configuration option IDs. It does seem that there is at least some effort in that project to achieve the result you desire.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager https://networkmanager.pages.freedesktop.org/NetworkManager/NetworkManager/nmcli.html
@hummeltech do you have more precise information on the effort you have been mentioning? I have trouble finding that in the links you provided.
I think the reference is to the deprecation notices added in this commit.
Those deprecations are to stop using connection.type to specify these types of connections however.
From the man pages.
Table 1. Options for all connections
┌────────────┬───────────────────────────┬───────────────────────────────┐
│Alias │ Property │ Note │
├────────────┼───────────────────────────┼───────────────────────────────┤
│type │ connection.type │ This alias also accepts │
│ │ │ values of bond-slave, │
│ │ │ team-slave and bridge-slave. │
│ │ │ They create ethernet │
│ │ │ connection profiles. Their │
│ │ │ use is discouraged in favor │
│ │ │ of using a specific type with │
│ │ │ master option. │
├────────────┼───────────────────────────┼───────────────────────────────┤
│con-name │ connection.id │ When not provided a default │
│ │ │ name is generated: │
│ │ │ <type>[-<ifname>][-<num>]). │
├────────────┼───────────────────────────┼───────────────────────────────┤
│autoconnect │ connection.autoconnect │ │
├────────────┼───────────────────────────┼───────────────────────────────┤
│ifname │ connection.interface-name │ A value of * will be │
│ │ │ interpreted as no value, │
│ │ │ making the connection profile │
│ │ │ interface-independent. Note: │
│ │ │ use quotes around * to │
│ │ │ suppress shell expansion. │
│ │ │ For bond, team and bridge │
│ │ │ connections a default name │
│ │ │ will be generated if not set. │
├────────────┼───────────────────────────┼───────────────────────────────┤
│master │ connection.master │ Value specified here will be │
│ │ │ canonicalized. It can be │
│ │ │ prefixed with ifname/, uuid/ │
│ │ │ or id/ to disambiguate it. │
├────────────┼───────────────────────────┼───────────────────────────────┤
│slave-type │ connection.slave-type │ │
└────────────┴───────────────────────────┴───────────────────────────────┘
Thank you, yes, I believe I probably mistook that or a similar change when browsing the commit history, I didn't do a very thorough search, so it's likely. The problem, as I see it, is that in order to do this right, you will need to maintain versioned matrices of supported properties and values, this would leave any unwelcoming language remaining within the module's code (and potentially add more in the future). I have, however, been working on something that might be of help in this effort. One possible solution is to query nmcli directly for a list of available properties. #3141 does that, but limited only to wifi & wifi_sec. As it is currently, it does not know anything about the possible values for those properties, which is also something that would be lacking in order to resolve this issue.
Created an issue at nmcli to see what's happening - https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/779
According to that issue, the NM team is actively working on this. They anticipate to be done with this also for nmcli in mid 2022. Let's revisit this topic by then.
The NM issue has been auto-closed again (https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/779), apparently still nothing happened :-( There's a new PR in this repo (#6108) using this language and it makes me really sad that there are still not even suggestions on which terms to use instead, so that these could not even be added as aliases...