Hi,
one of the Nmstate ours accidentally used Nmstate on a machine after updating NM without restarting it on CentOS 8. Therefore the system used libnm 1.20 with NM 1.14. This resulted in an error like
Connection adding failed: error=nm-connection-error-quark: bridge.vlans: unknown property (7)
How can we improve this error message?
My initial idea would be to compare the versions of NM and libnm in Nmstate and warn/abort if there is a mismatch: AFAICS we can check the NM version with NMClient.get_version() and the libnm version seems to be available with
struct.unpack("xBBB", struct.pack(">I", NM.utils_version()))
(not so convenient that the version identifiers are in different encodings, to be honest).
How about we add a warning/an error to Nmstate in case the versions mismatch? Do you prefer a warning or an error? Do you have other suggestions?
Kind regards Till
-- Till Maas He/His/Him Ansible RHEL Networking System Role Maintainer
Red Hat GmbH, https://www.redhat.com/de, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael O'Neill, Tom Savage, Eric Shander
On Fri, 2019-11-22 at 21:52 +0100, Till Maas via networkmanager-list wrote:
Hi,
one of the Nmstate ours accidentally used Nmstate on a machine after updating NM without restarting it on CentOS 8. Therefore the system used libnm 1.20 with NM 1.14. This resulted in an error like
Connection adding failed: error=nm-connection-error-quark: bridge.vlans: unknown property (7)
How can we improve this error message?
NM cannot improve this. Version 1.14 did not know that in the future "bridge.vlans" would be a valid property.
The error message is anyway mostly for debugging/logging. An application should create settings that it knows are valid (according to the targeted NM API). It's not clear how it could meaningfully interpret and react on an error.
My initial idea would be to compare the versions of NM and libnm in Nmstate and warn/abort if there is a mismatch: AFAICS we can check the NM version with NMClient.get_version() and the libnm version seems to be available with
struct.unpack("xBBB", struct.pack(">I", NM.utils_version()))
regarding ">I": the number is in native endianness, not BE.
def nm_decode_version(v = None): if v is None: v = NM.utils_version() return ((v >> 16) & 0xFF, (v >> 8) & 0xFF, ( v ) & 0xFF)
You can also print it in in hex, which gives 0x11503, meaning 0x1.0x15.0x3, which is 1.21.3.
The major benefit of this encoding is that you can compare versions by number.
def nm_encode_version(major, minor, micro): return (major << 16) | (minor << 8) | micro
if NM.utils_version() < nm_encode_version(1, 20, 0): warn("version missmatch")
or just
if NM.utils_version() < 0x11400: # 1.20.0 warn("version missmatch")
(not so convenient that the version identifiers are in different encodings, to be honest).
Hm, right. The value on D-Bus is a string, so it's nicer to read in d- feet/busctl. The value in libnm is numeric, so it's nicer to compare the value directly...
How about we add a warning/an error to Nmstate in case the versions mismatch? Do you prefer a warning or an error? Do you have other suggestions?
Sounds fine. A warning might suffice.
best, Thomas
On Sat, Nov 23, 2019 at 9:58 AM Thomas Haller via networkmanager-list < networkmanager-list@gnome.org> wrote:
On Fri, 2019-11-22 at 21:52 +0100, Till Maas via networkmanager-list wrote:
Hi,
one of the Nmstate ours accidentally used Nmstate on a machine after updating NM without restarting it on CentOS 8. Therefore the system used libnm 1.20 with NM 1.14. This resulted in an error like
Connection adding failed: error=nm-connection-error-quark: bridge.vlans: unknown property (7)
How can we improve this error message?
NM cannot improve this. Version 1.14 did not know that in the future "bridge.vlans" would be a valid property.
The error message is anyway mostly for debugging/logging. An application should create settings that it knows are valid (according to the targeted NM API). It's not clear how it could meaningfully interpret and react on an error.
My initial idea would be to compare the versions of NM and libnm in Nmstate and warn/abort if there is a mismatch: AFAICS we can check the NM version with NMClient.get_version() and the libnm version seems to be available with
struct.unpack("xBBB", struct.pack(">I", NM.utils_version()))
regarding ">I": the number is in native endianness, not BE.
def nm_decode_version(v = None): if v is None: v = NM.utils_version() return ((v >> 16) & 0xFF, (v >> 8) & 0xFF, ( v ) & 0xFF)
You can also print it in in hex, which gives 0x11503, meaning 0x1.0x15.0x3, which is 1.21.3.
The major benefit of this encoding is that you can compare versions by number.
def nm_encode_version(major, minor, micro): return (major << 16) | (minor << 8) | micro
if NM.utils_version() < nm_encode_version(1, 20, 0): warn("version missmatch")
or just
if NM.utils_version() < 0x11400: # 1.20.0 warn("version missmatch")
(not so convenient that the version identifiers are in different encodings, to be honest).
Hm, right. The value on D-Bus is a string, so it's nicer to read in d- feet/busctl. The value in libnm is numeric, so it's nicer to compare the value directly...
How about we add a warning/an error to Nmstate in case the versions mismatch? Do you prefer a warning or an error? Do you have other suggestions?
Sounds fine. A warning might suffice.
+1 for a warning. knmstate is using libnm in a container and contacting the host NM service though a mounted socker. So in their case, the versions may be different indeed.
I would also like to see it added to the "capabilities" report:
https://github.com/nmstate/nmstate/blob/e90fd3e07c482ec8e2038c6c65b86809ffab...
This way the client may decide what to do with the information (like knmstate).
best, Thomas _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Hi,
Am Mi., 27. Nov. 2019 um 11:02 Uhr schrieb Edward Haas edwardh@redhat.com:
+1 for a warning. knmstate is using libnm in a container and contacting the host NM service though a mounted socker. So in their case, the versions may be different indeed.
I would also like to see it added to the "capabilities" report:
https://github.com/nmstate/nmstate/blob/e90fd3e07c482ec8e2038c6c65b86809ffab...
How do you think it should look like? Should the capabilities report the libnm version?
Kind regards Till
This way the client may decide what to do with the information (like knmstate).
On Wed, Nov 27, 2019 at 12:06 PM Till Maas till@redhat.com wrote:
Hi,
Am Mi., 27. Nov. 2019 um 11:02 Uhr schrieb Edward Haas <edwardh@redhat.com
:
+1 for a warning. knmstate is using libnm in a container and contacting the host NM
service though a mounted socker.
So in their case, the versions may be different indeed.
I would also like to see it added to the "capabilities" report:
https://github.com/nmstate/nmstate/blob/e90fd3e07c482ec8e2038c6c65b86809ffab...
How do you think it should look like? Should the capabilities report the libnm version?
Yes, it will be nice to report the NM and libnm versions. It can even report Nmstate version and an optional schema version. Any metadata that can help the client make better decisions.
Kind regards Till
This way the client may decide what to do with the information (like
knmstate).
-- Till Maas He/His/Him Ansible RHEL Networking System Role Maintainer
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Laurie Krebs, Michael O'Neill, Thomas Savage
st 27. 11. 2019 v 11:25 odesílatel Edward Haas via networkmanager-list networkmanager-list@gnome.org napsal:
On Wed, Nov 27, 2019 at 12:06 PM Till Maas till@redhat.com wrote:
Hi,
Am Mi., 27. Nov. 2019 um 11:02 Uhr schrieb Edward Haas edwardh@redhat.com:
+1 for a warning. knmstate is using libnm in a container and contacting the host NM service though a mounted socker. So in their case, the versions may be different indeed.
I would also like to see it added to the "capabilities" report:
https://github.com/nmstate/nmstate/blob/e90fd3e07c482ec8e2038c6c65b86809ffab...
How do you think it should look like? Should the capabilities report the libnm version?
Yes, it will be nice to report the NM and libnm versions. It can even report Nmstate version and an optional schema version. Any metadata that can help the client make better decisions.
Is there any progress in this discussion? Is the effort tracked somewhere?
Kind regards Till
This way the client may decide what to do with the information (like knmstate).
-- Till Maas He/His/Him Ansible RHEL Networking System Role Maintainer
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Laurie Krebs, Michael O'Neill, Thomas Savage
networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Hi,
Am Mo., 9. Dez. 2019 um 19:58 Uhr schrieb Petr Horacek phoracek@redhat.com:
Is there any progress in this discussion? Is the effort tracked somewhere?
it is tracked in Jira:
https://nmstate.atlassian.net/browse/NMSTATE-287 https://nmstate.atlassian.net/browse/NMSTATE-288 https://nmstate.atlassian.net/browse/NMSTATE-289
There was no further discussion.
Kind regards Till
nmstate-devel@lists.fedorahosted.org