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:
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