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
Hi Edy and Fernando,
This is what I found to workaround the VLAN MTU bug:
1. Include vlan interface in desired state if base-iface changed
its MTUs.
2. Place vlan interface __after__ other interface when activation
To test whether step 2 works, I created patch:
http://pastebin.test.redhat.com/816035
It works well when I include both vlan and base-iface in the same
yml file with base-iface changed its MTU.
Hope this helps.
--
Gris Ge
Hi,
in
https://github.com/nmstate/nmstate/blob/master/tests/integration/conftest.p…
there is a fixture to restore the Nmstate state after test runs. This
happens unconditionally for all interfaces and causes failures when
Nmstate does not actually support setting the reported state. I saw
this so far with podman when there is a tap interface in the container
that made it choke. Also it fails on other systems:
https://nmstate.atlassian.net/browse/NMSTATE-275
Do we really need it like this? Can we at least limit it to only eth1
and eth2? AFAIU it will not remove any left-over profiles from the
tests anyhow so eth1 and eth2 would be the only interfaces that are
affected by this. But AFAIU, the tests fixtures clean up eth1/eth2
also all the time already.
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
Hi,
I've proposed #586 <https://github.com/nmstate/nmstate/pull/586> but I am
having some issues to test it.
Summary of the proposed solution:
If we are trying to edit an interface and it doesn't have an active profile
then nmstate is going to delete all the profiles related to this interface
and create a new one. If it has an active profile then use it.
Issue:
I have tested it manually and it works and also the proposed integration
test works when run alone. But the proposed test doesn't work together with
the rest of the integration tests because at this point nmstate have
created a new active profile.
Any suggestion on how could we test this better?
Thanks,
Fernando.
Hi Thomas,
with NM master, we now see a deprecation warning in our CI:
=============================== warnings summary ===============================
1089tests/integration/bond_test.py::test_add_and_remove_bond_with_two_slaves
1090 /usr/lib/python3.6/site-packages/libnmstate/nm/device.py:241:
DeprecationWarning: NM.Device.set_managed is deprecated
1091 dev.set_managed(True)
Saw it with this build from Copr: NetworkManager-1.21.2-1.9242b5ebc1.el8.x86_64
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