[OpenWrt-Devel] "UCI overlay" proposal

[David Lang]

 On Thu, 05 Mar 2015 13:36:10 +0100, Matthias Schiffer wrote:
> Hi,
> during the development of our Freifunk firmware framework "Gluon" 
> we've
> come to the conclusion that the current UCI configuration format 
> using
> static files doesn't always fit our needs. Therefore we propose a new
> feature we've called "UCI overlays".
>
> The basic idea is that we'd like to provide UCI configuration by 
> other
> means than the static files in /etc/config, for example from a 
> database
> or generated by scripts on the fly (the latter being our main usecase 
> -
> we'd like to generate configuration for netifd and fw3 based on
> meta-configuration data). This should work transparently, without
> needing changes in the config consumers (applications).
>
> The overlay-provided configuration packages should be merged with the
> config read from /etc/config. We'd like to generate both config 
> sections
> which may be overruled by corresponding options in /etc/config, and
> read-only sections which can't be changed by the user through UCI.
>
> We see two different ways to implement this:
>
> (1) Make the "overlay" an alternative backend which uses the "file"
> backend to merge generated config with the one from files
>
> (2) Introduce overlays as a new concept in libuci
>
>
> While the first option would need less changes in libuci, it doesn't
> allow stacking different overlays, so we're in favour of option 2.
>
> Both ways would need a config file (/etc/uci.conf?) to configure the
> overlays being used. Our plan is to implement overlays as dlopen-able
> plugins loaded from somewhere like /lib/uci/overlay so it is possible
> for other packages to provide overlay implementations.
>
> In addition, we'd like to add a new attribute "readonly" to the
> uci_element structure so changing read-only configuration will fail 
> as
> soon as someone tries to uci_set it.
>
> Does this sound reasonable? We can develop the needed extensions
> ourselves, but of course we'd like to get this feature upstream to 
> avoid
> carrying the patches downstream indefinitly, so we're eager to know 
> what
> you think of this proposal.

 Should this be built in to uci, or should this be a set of utilities 
 that take /etc/config/wireless.d/* and create /etc/config/wireless when 
 run (which then gets used normally)?

 You can then have scripts, database tools, config management tools 
 (puppet, chef, etc) drop things in such directories and the utilities 
 can run in cron (or use inotify in an advanced setup) to notice that 
 there was a change and do the appropriate thing to re-read the config.

 Building it into uci is more elegant, but I worry that having it that 
 integrated will mean that each new way to create config info will end up 
 requiring changes to uci. File based is a little less elegant, but it 
 makes it much easier for people to add new ways to do things.

 If you are assembling /etc/config/wireless from 
 /etc/config/wireless.d/* you can just say that the resulting file is the 
 combination of all the included files, and it's up to the admin to avoid 
 conflicts between the pieces. If you take /etc/config/wireless and 
 overlay other things on it, you have the question of how do you negate 
 something that was in the base file.



 I do think that something along these lines should be done. It would be 
 very nice to be able to break up existing config files a little bit (for 
 example, /etc/config/network split raw interfaces from bridge configs 
 from switch configs). And it would be great to be able to have a config 
 management tool be able to just add-on to the base config, replacing 
 part of it, without the config management tool needing to manage 
 everything in the file.

 Over on the CeroWRT list we are discussing what things are in CeroWRT 
 that have not yet been unstreamed into OpenWRT, and most of them come 
 down to config items. Some of them are 'fairly' small (like renaming 
 interfaces by function, so you have an interface named WAN rather than 
 eth0), while others are very fundamental (routing between each wifi 
 interface and the wired network instead of bridging). An overlay or 
 name.d approach would make it much easier for these different approaches 
 to be presented as packages that can be added to OpenWRT without forcing 
 everyone to change to them.

 David Lang
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel