On Fri, 2019-11-22 at 21:52 +0100, Till Maas via networkmanager-list
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
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
def nm_encode_version(major, minor, micro):
return (major << 16) | (minor << 8) | micro
if NM.utils_version() < nm_encode_version(1, 20, 0):
if NM.utils_version() < 0x11400: # 1.20.0
(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
Sounds fine. A warning might suffice.