RFC: Drop sysconfig references in interface definitions in /etc/config/gluon?

[lemoer]

During implementation of https://github.com/freifunk-gluon/gluon/pull/2480, I stumbled across some difficulties regarding the sysconfig references (/) in interface definitions in /etc/config/gluon.

Problem

Suppose this is a snippet in /etc/config/gluon:

config interface 'iface_lan'
	option name '/lan'
	list role 'client'

And /lan is the resolved to:

root@kuhbachtal00:/etc/config# cat /lib/gluon/core/sysconfig/lan_ifname 
eth1 eth2 eth3 eth4

Then we would like to show something like this in the UI:

Assume, the user changes the situation to the following:

At that point, we can no longer use the reference /lan in /etc/config/gluon. So we need to store something like this:

config interface 'iface_eth1'
	option name 'eth1'
	list role 'client'

config interface 'iface_eth2'
	option name 'eth2'
	list role 'client'

config interface 'iface_eth3'
	option name 'eth3'
	list role 'client'

config interface 'iface_eth4'
	option name 'eth4'
	list role 'mesh'

Meaning, we need to resolve the reference in this case and store individual interfaces for each network interface. This raises the question whether the references (starting with /) are still useful at all?

Suggested Action

Drop references to sysconfig (starting with /) and always store information for each individual network interface separately (from the beginning).

Drawback of the Suggested Action

The sysconfig options *_ifname are currently regenerated from /etc/board.json on every gluon-reconfigure. This means, changes from OpenWrt in /etc/board.json are directly propagated to gluon on every upgrade. If we stop using this mechanism, we do not propagate the changes from /etc/board.json to gluon on every upgrade.

This would mean that if e.g. eth0 changes from wan to lan and eth1 changes from lan to wan in an OpenWrt release, we would need to introduce specific migration for that downstream in gluon.

Please comment your opinion.

[neocturne]

The whole reason for the new configuration structure is to keep interface names out of /etc/config/gluon for common configurations.

I think this should also be reflected in the UI: The interfaces should just be called "LAN" and "WAN" (or "Ethernet" for the single iface case) like in the current wired mesh setting. This way, a user doesn't need to know which interface refers to which port, and all changes that are made through this UI can be migrated robustly.

To allow splitting the interfaces, I imagine something like an "add" button that allows to create a new interface section - which could either be a VLAN, or simply an individual eth interface. This configuration would require knowledge of interface names and might break in rare cases on major OpenWrt updates, so it should only be used to accommodate for unusual requirements.

[AiyionPrime]

The add button was something @lemoer and I talked about a week ago and figured it might be cleaner to just keep it in mind for later, but not include the functionality in this PR yet.

[lemoer]

Another option would be to add indexing [i] to the reference syntax and allow references like /lan[0] to reference the first interface stored in /lib/gluon/core/sysconfig/lan_ifname:

config interface 'iface_lan_1'
	option name '/lan[0]'
	list role 'client'

config interface 'iface_lan_2'
	option name '/lan[1]'
	list role 'client'

config interface 'iface_lan_3'
	option name '/lan[2]'
	list role 'client'

config interface 'iface_lan_4'
	option name '/lan[3]'
	list role 'mesh'

This syntax can be used from the beginning.

To allow splitting the interfaces, I imagine something like an "add" button that allows to create a new interface section - which could either be a VLAN, or simply an individual eth interface.

For VLAN creation or additional eth interfaces, this would work well. But for splitting the sysconfig referenced interfaces, things would be more complicated.

First of all, to split interfaces, the button would work different than to add vlans or additional eths. The button would then do the following:

1. Delete (or disable) the interface iface_lan.
2. Create multiple interfaces iface_eth1, iface_eth2, iface_eth3, iface_eth4.

Since this button would also delete interfaces, I think it should no longer be the "add interface" button but a separate button called "split interface lan" or something like this.

Once this is done, we would also need a button called "merge lan interface" that reverses this action:

1. Delete all interfaces iface_eth1, iface_eth2, iface_eth3, iface_eth4.
2. Create (or reenable) the interface iface_lan.

And in case we actually delete iface_lan (and do not just disable it), we would also need to make sure, that gluon-reconfigure does not recreate the section iface_lan while the interface was split by the user. Otherwise we would have conflicting sections iface_lan and iface_eth1, iface_eth2, iface_eth3, iface_eth4.

In my opinion, having these three buttons is not very intuitive:

• "Add interface"
• "Split interface lan"
• "Merge interface lan"

If we would introduce the indexing syntax /lan[0], we could handle interfaces individually from the beginning. Therefore no "interface splitting" would be necessary and the two buttons "Split interface lan" and "Merge interface lan" could be avoided. Then there would just be a simple "Add interface" button to add additional eths or VLAN interfaces. Also, we would not have to pay special attention to whether the interfaces are split or not during gluon-reconfigure.

What do you think?

[lemoer]

This is not wanted.