[OpenWrt-Devel] "UCI overlay" proposal

[Zefir Kurtisi]

David,

I do not disagree, and in fact I was not proposing a new configuration format.

What I tried to point out was
a) maintaining a 'meta-configuration' for some config overlay very quickly becomes
very challenging and resource consuming
b) if the format has to be changed, in OpenWRT JSON should be the obvious choice
from a pragmatic point: most of the configuration today already is converted to
JSON at runtime to be passed to the various ubus services.

As for the inherent problem of standardizing a continuously changing
configuration, that's what I described as the 'heaviest part'. Considering that
there are snmp MIBs released decades ago and (with gradual extensions) still used
today, difficult but doable.


Anyway, uci is not bad as is generally and does not need a replacement. We have
our JSON config overlay and it is doing ok. Alas, it would be a waste of resources
if multiple parties were cooking their proprietary overlay system when everybody
is trying to reach similar goals.


On 03/07/2015 12:00 AM, David Lang wrote:
> One other thought. If there is a desire to change the format, let's pick a format
> that's already in use for configuring system rather than inventing yet another
> one. We should survey the tools that are being written for managing software
> defined datacenters (openstack and similar) and see if we can use one of those
> config languages (either as-is or with an automated conversion back and forth)
> 
> David Lang
> 
> On Fri, 6 Mar 2015, David Lang wrote:
> 
>> changing the format doesn't solve the problem, it just causes churn in all the
>> software.
>>
>> The problem is the lack of standardization and the fact that the way things are
>> configured changes over time. Not everything is configured in UCI (and this will
>> always be the case because it's not worth trying to change every piece of
>> software available)
>>
>> When you try to design a "standardized config space" that will work in the
>> future for equipment and software that nobody has imagined yet, you are either
>> going to go crazy-complicated to try and cover everything and have people going
>> cross-eyed trying to understand the spec, or you are going to lock things down
>> to be so ridged that new things will be working around your config spec. The
>> best that you can do is to setup a framework to keep the configs from stepping
>> on each other and try to converge similar software to use the same terms in the
>> config where it makes sense (remember, the newcomer may have a better way of
>> looking at the problem, so trying to force it to define it's config the way the
>> legacy things did it can cause big problems)
>>
>> I'm all for tools to convert the format to whatever you want to use, and (as I
>> posted earlier), to have tools to assemble/generate the configs, but requiring
>> changes to every piece of software to just change the format requires more than
>> "every langauage can understand JSON"
>>
>> David Lang
>>
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel