statd: add interface type to operational data

[rical]

An iana or infix interface type is derived from "ip link" data. Such as loopback -> iana-if-type:softwareLoopback.

This patch adds support for the following types:
loopback, ethernetCsmacd, veth, l2vlan and bridge.

Example data:

{
  "ietf-interfaces:interfaces": {
    "interface": [
      {
        "name": "lo",
        "type": "iana-if-type:softwareLoopback",
        "oper-status": "unknown",
        "if-index": 1
      },
      {
        "name": "e0",
        "type": "iana-if-type:ethernetCsmacd",
        "oper-status": "up",
        "if-index": 2
      },
      {
        "name": "e0.100",
        "type": "iana-if-type:l2vlan",
        "oper-status": "down",
        "if-index": 3
      },
      {
        "name": "br0",
        "type": "iana-if-type:bridge",
        "oper-status": "down",
        "if-index": 4
      },
      {
        "name": "veth1",
        "type": "infix-if-type:veth",
        "oper-status": "down",
        "if-index": 5
      }
    ]
  }
}

[troglobit]

@wkz what do you think, should this perhaps be derived from the interface type in the running datastore instead of duplicated in operational?

[rical]

@wkz what do you think, should this perhaps be derived from the interface type in the running datastore instead of duplicated in operational?

Isn't the running datastore based on configuration data? I thought the idea with operational data was to get it directly from the source i.e. the running kernel.

[troglobit]

Yes mostly, and that's the crux of it. The interface type is derived from a) physical interfaces that exist at first boot (factory-config), like ethernetCsmacd for all ethN/eN interfaces, but also loopback. Other types are inferred from the name when creating them, e.g. veth pairs. See ifchange_cand_infer_veth().

I'm just concerned we start bookkeeping this core knowledge in more than one place, so curious what @wkz thinks about it.

[wkz]

I agree that it is double bookkeeping, but I think it's worth it.

Random thoughts in no particular order:

• Knowing that the operational state matches the kernel's view as closely as possible is very useful from a debugging perspective. It can give us insights into discrepancies between what the user configured and what has been applied, without needing to get shell access on the box.
• One day, we might have interfaces that are not part of the configuration - that are dynamically created by some daemon, for example. What do we do at that point?
• If we find a rouge interface on the box that isn't in the config, what type do we report then?

[troglobit]

Good points all around, and I agree. I'm just worried about duplication and keeping it all in sync. I guess we should put things like this in a checklist or auto test to ensure we don't drift apart in the various backends.

Also, see https://github.com/addiva-elektronik/infix-planning/issues/34