[RFE] Allowing referring bond/bridge/vlan/etc port using profile name

[ryanbowen]

Right now the interface name is required to configure an interface. It would be nice to be able to apply config to ethernet interfaces by using either the permanent MAC address or the name.

NetworkManager allows you to create connection profiles that are mapped to interfaces by MAC address without requiring the interface name. This is nice because it saves you when certain NIC manufacturers (looking at you, Mellanox...) decide to make changes to drivers or firmware that alter the "predictable" interface names which would otherwise cause host networking to break on boot. Obviously this can be solved with udev rules but it would be nice to not have to resort to them.

[cgwalters]

This is strongly related to #2301 - note we solved that by writing systemd .link files.

Obviously this can be solved with udev rules but it would be nice to not have to resort to them.

Yes, but note systemd .link files are already declarative and much nicer than udev rules.

[cathay4t]

Tihs is already supported since 2.2.10. For example:

---
interfaces:
  - name: wan0
    type: ethernet
    state: up
    identifier: mac-address
    mac-address: 1e:bd:23:e9:fb:94
    ipv4:
      enabled: true
      dhcp: true
    ipv6:
      enabled: true
      dhcp: true
      autoconf: true

[cathay4t]

I have created document at https://nmstate.io/features/mac_identifier.html

[cathay4t]

@cgwalters ^^

[ryanbowen]

Thanks, great to hear that this is supported now. Can this be used as a way to use MAC addresses to specify bond member ports? Does nmstate match the names used in interface.link-aggregation.port(s) to nmstate interface.name or directly to kernel device names?

i.e. does this work if the kernel device names aren't bond0-member0 and bond0-member1:

interfaces:
- name: bond0
  type: bond
  state: up
  link-aggregation:
    mode: 802.3ad
    options:
      ...
    port:
    - bond0-member0
    - bond0-member1
- name: bond0-member0
  type: ethernet
  state: up
  identifier: mac-address
  mac-address: 1E:BD:23:E9:FB:94
  ...
- name: bond0-member1
  type: ethernet
  state: up
  identifier: mac-address
  mac-address: 1E:BD:23:E9:FB:95
  ...

Alternatively, is there a way to specify the parent/controller/master of an interface on the child?

- name: bond0-member0
  type: ethernet
  state: up
  identifier: mac-address
  mac-address: 1E:BD:23:E9:FB:94
  controller: bond0

For context, we run LACP for the majority of our hosts and the interface renaming hurts the most with bonds because the we end up with no functional members. With non-bonded interfaces, it seems NetworkManager will fall back to a default profile with DHCP on one of the interfaces when no other connection profiles match, so at least we don't lose networking completely. With LACP bonds, when things get renamed we end up without any functional networking at all and have to fix it by getting on the console via the BMC which doesn't scale. I just still haven't found the magic solution that works with LACP bonds AND can be applied via nmstate.

[bowenr-deshaw]

@cathay4t @cgwalters Do either of you know if one of the strategies above allow specifying bond member ports in a way that matches based on MAC and not kernel device name?

[cathay4t]

@ryanbowen Currently nmstate does not support referring the profile name of a interface as port yet. But workaround could be:

1. Create bond with empty port list.
2. Add port to this bond.

For example, apply these two YAML seperately will work for your use case:

---
interfaces:
- name: bond0
  type: bond
  state: up
  link-aggregation:
    mode: balance-rr
    ports: []

---
interfaces:
- name: bond0-member0
  type: ethernet
  state: up
  identifier: mac-address
  mac-address: c2:9f:53:47:5d:08
  controller: bond0

I have create https://issues.redhat.com/browse/RHEL-1745 to trace the effort on supporting this in single YAML file.

[ryanbowen]

@cathay4t I'm unable to view that Red Hat Jira issue you mentioned (RHEL-1745), unless that's expected. We also have a RH support contract w/TAM services in case it's needed or helps.

[cathay4t]

@ryanbowen Please contact your TAM or support engineer for access. We are currently planning it for OCP 4.14 or later version, if you need backport to older version of openshift, please mention that to your TAM/support contact. Thank you!

[drawks]

This feature would be great, however all of the last several messages in this issue direct to resources off site and or refer to various commercial support contracts and/or tangental software. Can this issue please get an update that clearly communicates whether this feature is being worked on and if so what the expected release timeline is?

All the top level documentation for this project suggests that PRs are welcome, but pivoting issues to pay walled tickets and support contracts makes it hard to tell if progress is being made and/or coordinate additional contributions to the requested feature.

[cathay4t]

@drawks You may ignore those redhat links, they just tracks the effort of backport this feature into Red Hat linux. For upstream, I am currently working on this feature and expected to include it in next release 2.2.28 before 2024 Apr 26.

[hjensas]

Also for vlan interfaces it would be nice to be able to define the "base-iface" using a name.

Something like:

- name: net-iso
  type: ethernet
  identifier: mac-address
  mac-address: 52:54:00:5b:39:8b
- name: net-iso.101
  type: vlan
  state: up
  vlan:
    base-iface: net-iso
    id: 101
    protocol: 802.1q