On Sat, Nov 23, 2019 at 9:58 AM Thomas Haller via networkmanager-list <
[email protected]> 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/e90fd3e07c482ec8e2038c6c65b86809ffaba6ce/libnmstate/netinfo.py#L67
This way the client may decide what to do with the information (like
knmstate).
>
> best,
> Thomas
> _______________________________________________
> networkmanager-list mailing list
> [email protected]
> https://mail.gnome.org/mailman/listinfo/networkmanager-list
>
_______________________________________________
networkmanager-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/networkmanager-list
