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
[email protected]
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
