Hi Federico, Thanks for your reply, yeah i need to rethink my templates. i going to read some info first :-) For sure there are other priorities, there are many cool things to implement, this is a awesome project with great potential. I work with Ruckus devices and controllers at work and it would be great to switch to fully open software in a couple years.
Greets Op zondag 23 september 2018 09:59:44 UTC+2 schreef Federico Capoano: > > Hi Jeroen, > > yes it is possible to override templates and there are specific ways the > override work. > In short: lists will be summed up (usually you have a base list on which > you want to add to and don't want to redefine the whole list in each > override), strings or numbers will be simply overridden. > > The documentation of the configuration engine of OpenWISP > <http://netjsonconfig.openwisp.org/en/latest/general/basics.html#template> > explains how combining configuration templates works, including using > multiple templates, overriding and how the overriding is done. > > I highly suggest you to take the time to read the whole page. > > The OpenWRT Backend documentation page > <http://netjsonconfig.openwisp.org/en/latest/backends/openwrt.html> is > also very useful. > > Regarding having to duplicate the bridge members definition because > members are slightly different: maybe you don't need to do that. > There are two possible ways you may be able to solve this problem: > > 1. you could simply have all the possible members defined in the bridge, > OpenWRT will ignore members if the interface they refer to does not exist. > > 2. you could create a base template with an empty bridge (no members), and > then additional templates for all the frequent membership combinations you > need; then when assigning the templates, make sure the base template comes > first and the specialized template comes later > > Regarding the redundancy of the interface definition: it's true that > sometimes the definition in /etc/config/network is not needed. > It is needed only in certain cases as Oliver was explaining, but it is > done this way to keep the implementation simple. It could be improved in > the future but I think we all agree there are other things that have more > priority right now. > > I hope this helps! > > Federico > > > On Sunday, September 23, 2018 at 12:01:29 AM UTC+2, JeroenR wrote: >> >> I just discovered the device override :-) >> >> I question, it seems that the bridge members are appended instead of >> overridden. >> >> Example template: >> { >> "interfaces": [ >> { >> "type": "bridge", >> "bridge_members": [ >> "eth0.52" >> ], >> "name": "wlan52", >> "autostart": true, >> "network": "vif_vlan_52", >> "disabled": false, >> "addresses": [], >> "wireless": { >> "mode": "access_point", >> "radio": "radio0", >> "ssid": "Wifi1", >> "encryption": { >> "key": "************", >> "protocol": "wpa2_personal", >> "cipher": "ccmp" >> }, >> "isolate": false, >> "wmm": true, >> "wpa_disable_eapol_key_retries": true >> }, >> "delegate": 0, >> "force_link": 1 >> } >> ] >> } >> Bridge member "eth0.52" need to be "eth0.1" on device level, so i add >> following config at device: >> { >> "interfaces": [ >> { >> "type": "bridge", >> "bridge_members": [ >> "eth0.1" >> ], >> "name": "wlan52", >> "autostart": true, >> "network": "vif_vlan_52", >> "disabled": false, >> "addresses": [], >> "delegate": 0, >> "force_link": 1 >> } >> ] >> } >> >> But i get the following results: >> >> config interface 'vif_vlan_52' >> option auto '1' >> option delegate '0' >> option enabled '1' >> option force_link '1' >> option ifname 'eth0.52 eth0.1' >> option proto 'none' >> option type 'bridge' >> >> Is this expected behavior? How can i delete the template bridge member? >> >> >> >> -- You received this message because you are subscribed to the Google Groups "OpenWISP" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
