Bug 2095173
| Summary: | Nmstatectl gc should not generate config for down/absent interfaces | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Vitaly Grinberg <vgrinber> |
| Component: | nmstate | Assignee: | Fernando F. Mancera <ferferna> |
| Status: | CLOSED ERRATA | QA Contact: | Mingyu Shi <mshi> |
| Severity: | urgent | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 8.7 | CC: | ccrum, ferferna, fge, jiji, jishi, mfilanov, network-qe, oamizur, till, trwest, yfirst |
| Target Milestone: | rc | Keywords: | Triaged |
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | No Doc Update | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-11-08 09:17:52 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 2095172 | ||
@vgrinber why is the state "absent" ? according to the documentation state can be "up" or "down" (In reply to Ori Amizur from comment #1) > @vgrinber why is the state "absent" ? according to the > documentation state can be "up" or "down" Hey Ori, I tried both "down" and "absent" - neither of them put the interface down. (I saw an example for "absent" in https://nmstate.io/examples.html) Looks like we have an old version of nmstate in the pod. The version that we have is 1.3.0 and it does not support shutting down interfaces. we need to check if there is a newer version that we can install https://github.com/openshift/assisted-service/blob/cca3023940a8f8faad69419a5e53faa1d610ffaf/Dockerfile.assisted-service#L39-L40 Tried to change connection file directly in NetworkManager. NMState just manipulates these files directly. Couldn't cause the NIC to be disabled. Seems to be a limitation of NetworkManager. Newer versions indeed produce a different result:
Config:
=======
interfaces:
- mac-address: de:ad:bb:ef:00:25
name: ens4
state: down
Old version:
============
[nmagnezi@nmagnezi ~]$ nmstatectl --version
1.3.0
[nmagnezi@nmagnezi ~]$ nmstatectl gc test1
--- {}
The new version does yield a different result:
==============================================
[nmagnezi@rdu-infra-edge-03 ~]$ nmstatectl --version
nmstatectl 2.1.2
[nmagnezi@rdu-infra-edge-03 ~]$ nmstatectl gc test1
[2022-06-27T08:08:58Z WARN nmstate::ifaces::inter_ifaces] Setting unknown type interface ens4 to ethernet
[2022-06-27T08:08:58Z INFO nmstate::ifaces::inter_ifaces] Adding interface ens4 with type ethernet
---
NetworkManager:
- - ens4.nmconnection
- "[connection]\nautoconnect=true\nautoconnect-slaves=-1\nid=ens4\ninterface-name=ens4\ntype=802-3-ethernet\nuuid=739065e7-6e8f-5205-923f-530d8fd646f9\n\n[ipv4]\nmethod=disabled\n\n[ipv6]\nmethod=disabled\n"
The problem is that version 1.x.x is a part of CentOS 8 Stream and 2.x.x a part of CentOS 9 Stream. Thus, if we plan to use 1.x.x we will need a backport.
Per comment$5, I have opened an issue to NMState, in case we need a backport: https://github.com/nmstate/nmstate/issues/1946 Hello! So there are two different issues here. (In reply to Ori Amizur from comment #4) > Tried to change connection file directly in NetworkManager. NMState just > manipulates these files directly. Couldn't cause the NIC to be disabled. > Seems to be a limitation of NetworkManager. Exactly. Nmstate in gen_conf does not communicate with the NetworkManager service which is the place where the `state` of the connection or device is stored. That means, it is not possible to specify the state in the configuration file. A way to do this is to check that the configuration is missing in the output, therefore, the interface is on `down` or `absent` and then remove the configuration file directly. It is not a very shiny solution but it is a workaround. In the other hand: (In reply to Nir Magnezi from comment #5) > Newer versions indeed produce a different result: > > Config: > ======= > > interfaces: > - mac-address: de:ad:bb:ef:00:25 > name: ens4 > state: down > > Old version: > ============ > [nmagnezi@nmagnezi ~]$ nmstatectl --version > 1.3.0 > [nmagnezi@nmagnezi ~]$ nmstatectl gc test1 > --- {} > > > The new version does yield a different result: > ============================================== > [nmagnezi@rdu-infra-edge-03 ~]$ nmstatectl --version > nmstatectl 2.1.2 > [nmagnezi@rdu-infra-edge-03 ~]$ nmstatectl gc test1 > [2022-06-27T08:08:58Z WARN nmstate::ifaces::inter_ifaces] Setting unknown > type interface ens4 to ethernet > [2022-06-27T08:08:58Z INFO nmstate::ifaces::inter_ifaces] Adding interface > ens4 with type ethernet > --- > NetworkManager: > - - ens4.nmconnection > - > "[connection]\nautoconnect=true\nautoconnect-slaves=-1\nid=ens4\ninterface- > name=ens4\ntype=802-3-ethernet\nuuid=739065e7-6e8f-5205-923f- > 530d8fd646f9\n\n[ipv4]\nmethod=disabled\n\n[ipv6]\nmethod=disabled\n" > > > > The problem is that version 1.x.x is a part of CentOS 8 Stream and 2.x.x a > part of CentOS 9 Stream. Thus, if we plan to use 1.x.x we will need a > backport. This is a bug, version 2.X.X should not generate anything for interfaces that are down. I am going to work on it to fix it. Do you mind if I keep this bug to track the second issue? Thank you! Please, let me know what do you think about the first issue. Thanks! Hi @ferferna! I think the workaround you describe for the issue will do the job. Sure, please keep this bug to track the second issue. Cheers! @ferferna I am not sure I understand what was the suggested solution. Should the interfaces we want to be down be manipulated directly outside of NetworkManager ? @ferferna then what does https://nmstate.io/devel/api.html#interfacestate mean? Hello! There are 2 different ways to use Nmstate. By default Nmstate communicates with NetworkManager and configures the interfaces directly. This could be done by doing `nmstatectl apply example.yml`. (In reply to Michael Filanov from comment #11) > @ferferna then what does > https://nmstate.io/devel/api.html#interfacestate mean? In this case, the interface state means the interface is UP or DOWN as everyone could expect and as it is described in https://nmstate.io/devel/api.html#interfacestate But there is another way of use Nmstate which is the gen_conf mode. In the gen_conf mode, Nmstate won't communicate with NetworkManager at all, that means Nmstate will just generate a NetworkManager keyfile that matches the interface state. In this case, it is not possible to indicate to set the DOWN state because there is no communication happening between Nmstate and NetworkManager. So.. https://nmstate.io/devel/api.html#interfacestate is a little bit irrelevant. According to comment #6 (https://bugzilla.redhat.com/show_bug.cgi?id=2095173#c5) I understand that you are using the gen_conf mode.. isn't that correct? If you are not using the gen_conf mode then this is a bug and not a limitation. Also if you could provide detailed logs I could check what is happening too. Thank you! Fernando. Thanks for the explanation Fernando, you are correct we are using generate configuration command, and applying the configuration on the hosts. Do you suggest to take the nmstate file and appy it directly using `nmstatectl apply` on the host? The GC(generate configuration) mode of nmstate does not support `state: down` or `state: absent` of interface. It is a bug to nmstate 2.x when generating output for `state:down` interface. To solve your problem: * If you desire IPv4 and/or IPv6 disabled for certain interface, you state so with `state: up` for GC mode. * If you desire physical link down for certain interface, `state: down` to `nmstatectl apply` or `ip link set eth1 down` can help, but you have to run it after every reboot. Because there is no way in NetworkManager keyfile says I want this interface in link down state. Verified with:
nmstate-1.3.2-1.el8.x86_64
nispor-1.2.7-1.el8.x86_64
NetworkManager-1.39.10-1.el8.x86_64
`nmstatectl gc` doesn't generate for the interface with state down/absent/ignore
[11:35:22@kvm-08-guest02 ~]0# cat gc.yaml
interfaces:
- mac-address: de:ad:bb:ef:00:25
name: ens4
state: down
[11:36:12@kvm-08-guest02 ~]0# nmstatectl gc gc.yaml
--- {}
[11:36:19@kvm-08-guest02 ~]0# cat gc.yaml
interfaces:
- mac-address: de:ad:bb:ef:00:25
name: ens4
state: absent
[11:36:26@kvm-08-guest02 ~]0# nmstatectl gc gc.yaml
--- {}
[11:36:29@kvm-08-guest02 ~]0# cat gc.yaml
interfaces:
- mac-address: de:ad:bb:ef:00:25
name: ens4
state: ignore
[11:36:39@kvm-08-guest02 ~]0# nmstatectl gc gc.yaml
--- {}
[11:36:42@kvm-08-guest02 ~]0# cat gc.yaml
interfaces:
- mac-address: de:ad:bb:ef:00:25
name: ens4
state: up
[11:36:48@kvm-08-guest02 ~]0# nmstatectl gc gc.yaml
---
NetworkManager:
- - ens4.nmconnection
- '[connection]
id=ens4
uuid=c90aa3f8-71b7-4b6a-aab3-b284560a552d
type=ethernet
interface-name=ens4
[ethernet]
cloned-mac-address=DE:AD:BB:EF:00:25
[ipv4]
dhcp-client-id=mac
method=disabled
[ipv6]
addr-gen-mode=eui64
dhcp-duid=ll
dhcp-iaid=mac
method=disabled
[proxy]
'
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (nmstate bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2022:7465 |
Description of the problem: If a server has several NICs connected to the network, it's impossible to disable any of them completely through nmstaateconffig custom resource Release version: Operator snapshot version: OCP version: Browser Info: Steps to reproduce: 1. Configure following resource: apiVersion: agent-install.openshift.io/v1beta1 kind: NMStateConfig metadata: annotations: argocd.argoproj.io/sync-wave: '1' labels: app.kubernetes.io/instance: clusters nmstate-label: cnfdf12 name: cnfdf12 namespace: cnfdf12 spec: config: dns-resolver: config: search: - telco5gran.eng.rdu2.redhat.com server: - 127.0.0.1 - 10.11.5.19 interfaces: - ipv4: address: - ip: 10.8.34.30 prefix-length: 24 enabled: true ipv6: enabled: false macAddress: '3c:ec:ef:5f:a2:c4' name: eno1 state: up type: ethernet - macAddress: '3c:ec:ef:5f:a2:c5' name: eno2 state: absent type: ethernet routes: config: - destination: 0.0.0.0/0 next-hop-address: 10.8.34.254 next-hop-interface: eno1 table-id: 254 interfaces: - macAddress: '3c:ec:ef:5f:a2:c4' name: eno1 Actual results: Interface 'eno2' is up and assigned IP addresses (by DHCP) Expected results: Interface eno2 is down Additional info: