Checking libnm/NM version mismatch

[Till Maas]

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

[Thomas Haller]

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

[Edward Haas]

On Sat, Nov 23, 2019 at 9:58 AM Thomas Haller via networkmanager-list <
networkmanager-list(a)gnome.org&gt; 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/e90fd3e07c482ec8e2038c6c65b86809f...


This way the client may decide what to do with the information (like
knmstate).


>  best,
>  Thomas
>  _______________________________________________
>  networkmanager-list mailing list
>  networkmanager-list(a)gnome.org
>  https://mail.gnome.org/mailman/listinfo/networkmanager-list
>

[Till Maas]

Hi,

Am Mi., 27. Nov. 2019 um 11:02 Uhr schrieb Edward Haas <edwardh(a)redhat.com&gt;:
>  
> +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/e90fd3e07c482ec8e2038c6c65b86809f...

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).

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

[Edward Haas]

On Wed, Nov 27, 2019 at 12:06 PM Till Maas <till(a)redhat.com&gt; wrote:

>  Hi,
>
>  Am Mi., 27. Nov. 2019 um 11:02 Uhr schrieb Edward Haas <edwardh(a)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/e90fd3e07c482ec8e2038c6c65b86809f...
>
>  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
>
>

[Petr Horacek]

st 27. 11. 2019 v 11:25 odesílatel Edward Haas via networkmanager-list
<networkmanager-list(a)gnome.org&gt; napsal:
>  On Wed, Nov 27, 2019 at 12:06 PM Till Maas <till(a)redhat.com&gt; wrote:
> >
> > Hi,
> >
> > Am Mi., 27. Nov. 2019 um 11:02 Uhr schrieb Edward Haas <edwardh(a)redhat.com&gt;:
> > >
> >
> > > +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/e90fd3e07c482ec8e2038c6c65b86809f...
> >
> > 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(a)gnome.org
>  https://mail.gnome.org/mailman/listinfo/networkmanager-list

[Till Maas]

Hi,

Am Mo., 9. Dez. 2019 um 19:58 Uhr schrieb Petr Horacek <phoracek(a)redhat.com&gt;:

>  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

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