[OpenWrt-Devel] "UCI overlay" proposal

[David Lang]

On Tue, 10 Mar 2015, Zefir Kurtisi wrote:

> 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

It could be, but if you use the conf.d approach I don't see it being either very 
challenging or resource intensive.

> 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.

If the config format needs to be changed, I wouldn't oppose JSON. I'm just 
questioning why it would need to change at all. I don't see how it would help, 
either the overlay problem or the changing config problem.

David Lang

> 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