Hi everyone,
I recently realized that some bridge and L2 properties which weren't
working anymore on OpenWrt 21.02 had to be moved from the interface
UCI type to the new device UCI type in /etc/config/network.
I thought that in this release the old syntax would continue being
supported, however I see that this is not the case, because the stp
and macaddr directives were clearly being ignored until I moved those
from "interface" to "device", I either misunderstood the previous
discussions or there's something wrong here, I also do not see much
information about this breaking change in the release notes:
https://openwrt.org/releases/21.02/notes-21.02.1, am I missing
something?
Since I maintain a system called OpenWISP which aims to ease the
configuration management of a high number of OpenWrt based devices, I
find myself in a tricky situation because OpenWISP now basically won't
work fully with OpenWrt 21.02, moreover it needs to support older
OpenWrt versions for a while, so I want to ask: do you think it's ok
to generate both type of syntaxes (old and new) at the same time?
I would assume that an old openwrt version would ignore the new syntax
while a newer openwrt version would ignore the old syntax and use the
new one.
Is there a summary of the config syntax changes?
Originally posted on the mailing list but got no response there so I am reposting here with the hope of some clarification.
where a config-network-device stub exists for a logical interface,
it is preferred/used for layer two options
bad idea
do the practical testing on devices and handle version dependent config properly...
where a config-network-device stub exists for a logical interface,
it is preferred/used for layer two options
Do you know if this has this been explained in the release notes anywhere?
I ask because this is quite a problem for systems which manage existing devices.
Here's what can happen:
- a device is managed by a system which uses OpenWrt 19.07 configs
- the device is upgraded to OpenWrt 21.02, which ships the new configurations by default
- the management system sends the configs, but part of it won't work anymore
Now, if this change is known in advance, one can mitigate/work around the problem, but in my case I didn't find much information about this specific aspect.
bad idea
do the practical testing on devices and handle version dependent config properly...
Do you care to explain why it is a bad idea?
Thanks in advance.
it isn't, but given most devices will migrate forward in one-go, i don't think it's a point many would benefit from
you are the openwisp guy, you have 10x the knowledge about this stuff than myself... but as above... a typical end user will maintain a set of two config versions (for one or two devices) not the backend logic to detect and generate them conditionally...
sure, for instance;
- how long will old l2 options @interface continue to be supported on the newer devices?
- how do you plan to supress / interact with the automigration logic?
- how can you compress the various device combos (dsa, non-switch, swconfig still) into a single coherent recipe?
time to roll up the sleeves and get practical... ( you'll note the linked topic above is 7months old and this one around 5 )
1 Like