Yes it is ugly, using section type as prefix was intended to avoid any chance of name collisions.
uci -X show wireless shows no unnamed sections, and it uses prefix default_ for default_radio0 and default_radio1 named sections, that seems nicer.
Using config device 'default_device_lan' for br-lan and config device 'default_device_wan for eth0.2 is longer, but probably less ugly.
Sections switch could work without any prefix, and switch_vlan could use _vlanN as a suffix.
TP-Link Archer C2 AC750 would then have this in /etc/config/network:
config device 'default_device_lan'
option name 'br-lan'
option type 'bridge'
option ipv6 '1'
list ports 'eth0.1'
config device 'default_device_wan'
option name 'eth0.2'
option macaddr 'aa:bb:cc:dd:ee:ff'
config switch 'switch0'
option name 'switch0'
option reset '1'
option enable_vlan '0'
config switch 'switch1'
option name 'switch1'
option reset '1'
option enable_vlan '1'
config switch_vlan 'switch1_vlan1'
option device 'switch1'
option vlan '1'
option ports '1 2 3 4 6t'
config switch_vlan 'switch1_vlan2'
option device 'switch1'
option vlan '2'
option ports '0 6t'
(only showing sections which are unnamed as of OpenWrt 23.05)
Would the above be acceptable ?
Terraform
The goal is not to introduce arbitrary identifiers, but to have the initial configuration use only named sections, in order to have stable identifiers. Though it would be nice if they were the same on most OpenWrt devices.
Ideally, a terraform provider creates a resource by performing an API call, and in response it gets an id to be used for detecting drift between actual resource state and wanted configuration.
For some resources, the ID is part of resource description (e.g. name of S3 bucket), for others it is automatically generated (e.g. AWS EC2 instance id).
Initial OpenWrt configuration already has some resource already present, that requries importing them to terraform, in order to modify them or depend on their state.
At the moment, terraform provider requires import using the id, i.e. the name of the config section.
(For unnamed section, even terraform import openwrt_network_device.br_primary '@device[0]' works, but the resource still has id 'cfg030f15')
Until few hours ago I thought that terraform required providers to have an immutable id to identify a resource. That having the provider use name as id would make it impossible to change the name of any bridge. Not a huge issue with the initial br-lan bridge, but a problem for bridges created using Terraform. A user might want to rename br-guest2 to br-iot.
But according to this, providers using new Terraform Plugin Framework actually can support changing the id of a resource.
Still, using "name option" as resource id would be very far from ideal. It looks like luci api can get a section in one API call only by using section name (even cfgNUMBER), but cannot get a section based on one or more of its options' values.
For every bridge, the provider would have to get the whole network config. For switch_vlan the provider does not have anything like name, it would have to search for a section with both device and vlan options matching the resource, and use both options to construct some sort of unique id.
It would be a bit slower and needlesly more complex. Adding few strings to the initial configuration file seems like a much better option.
For completenes, using "name option" only for import, and then using unnamed section (cfgNUMBER) as the id would not work.
According to source it depends on:
- position of the section within the file (used as first two digits)
- section type
- option names
- values of string options
Removing br-lan would change cfgNUMBER id of eth0.2 device. Next terraform run, it would try to create new device for eth0.2, because it would look like it was deleted.
Modifying br-lan options should also change the cfgNUMBER, but experiment with renaming br-lan to br-notlan did not change it, it remained cfg030f15 even after reboot. No idea why.
