Wireguard interface naming (UCI and netifd)

[VincentR]

TL/DR:
Wireguard interfaces definition seems to break the relational nature of UCI by using option names and even types as values. Is there a functional reason? Should it change?

Summary/Example:
I'm currently testing wireguard and I was looking for some flexibility around the naming of the interface whilst retaining the rest of my configuration unchanged. The way it's currently implemented seems to create an unusual amount of friction.

Let's say I have an initial wireguard interface named 'wg0' in /etc/config/network. And I'm now deciding to change that interface name to 'wg1'.
Note: I was using the interface name as a reference in other places like my firewall config.

So I start with something like this:

• /etc/config/network

  ...
  config interface 'wg0'
      option proto 'wireguard'
      option private_key 'my_private_key'
      option addresses '10.10.10.10/32'
  
  config wireguard_wg0
      option endpoint_host 'myhost.mydomain.com'
      ...
  

• /etc/config/firewall

  ...
  config zone 'wireguard_zone'
      list network 'wg0'
  ...
  

When I change my interface to wg1, I end up having to rename the interface and change the type of the associated config(s). I also have to revisit every configuration file where I used that interface as a reference.

Expectation:
I feel this breaks the structure of UCI as a relational DB. Typically, config types are used to describe the schema and config names to uniquely refer to a config element. The values are within the config and associated with known option/list which belong to the type schema.

I would expect something like:

• /etc/config/network

  ...
  config interface 'my_wireguard_interface'
      option ifname 'wg0'
      option proto 'wireguard'
      option private_key 'my_private_key'
      option addresses '10.10.10.10/32'
  
  config wireguard_peer 'my_peer'
      option interface 'my_wireguard_interface'
      option endpoint_host 'myhost.mydomain.com'
      ...
  

• /etc/config/firewall

  ...
  config zone 'wireguard_zone'
      list network 'my_wireguard_interface'
  ...
  

With these changes, the UCI configuration would feel consistent.

Note: playing around with /lib/netifd/proto/wireguard.sh, it seems that the confusion between config name and interface name is complete and may be core to the netifd/ubus representation of the wireguard interface.

Question 1: is this design the result of a wireguard MVP which works and therefore stayed? or is there a reason that forces the structure?

Question 2: is there a plan to revisit this? I'm currently falling short of the task as I have a fair bit of learning to do around netifd and its intended use to get there.

Question 3: Should the "ip link" commands in wireguard.sh not be internal to netifd? (that's more for my own understanding - I don't have an issue with that part)

Thanks for any element of answer!

[jow]

Q1: that is my assumption as well, the initial implementation was made this way and then the design stayed. Another recent submission with a somewhat similar requirement opted for a more "traditional" structure after the initial dynamic type has been rejected: http://lists.openwrt.org/pipermail/openwrt-devel/2020-July/030301.html (previous remark: http://lists.openwrt.org/pipermail/openwrt-devel/2020-July/030249.html)

Q2: I am not aware of any, it needs someone driving the process. Also backwards compatibility and required LuCI changes need to be taken into account

Q3: there is no strict requirement to have these things internal. If we keep moving every possible bit of netlink support into netifd, we'd lose some benefits of the protocol handler modularity. The core would keep growing to accomodate for relatively rarely used features.