> On Feb 13, 2018, at 11:12 AM, Anton Ivanov <anton.iva...@cambridgegreys.com>
> On 02/13/18 17:31, Philip Prindeville wrote:
>> Well, before I write out a formal proposal… What about storing Openwrt
>> configs natively in YANG and then synthesizing appropriate config files out
>> of that for various subsystems (Ssh, network, firewall, DHCP, etc)?
> You cannot store something in yang. You can model how the storage looks in
> yang and have a datastore which complies with yang schema. Yang is schema,
> not data.
Well, in the simplest case, you’d have a flat text file with the Yang-modeled
>> We would probably need bi-directional conversion from YANG to UCI, etc.
> Do you mean yang modeled data?
> The schema used by most UCI modules is fairly trivial to be expressed in
> yang. The issue is more with access and presentation.
Sorry, when I said Yang I was also tacitly including XPath validation of much
of the configuration as well.
Properly done, you can do 100% configuration validation with XPath (so it
happens in the front end) and not have to build in any back-end magic.
>> so that if someone pushed a config into the box using Netconf, but then
>> ssh’d into it and looked at the UCI files, the UCI files would be coherent
>> with the “authoritative” configuration.
>> Likewise, if someone edited the UCI and then restarted a subsystem, the YANG
>> source-of-truth would get upgraded internally (and be visible in LUA, etc).
> You can use the current UCI data and map it out as yang datastore. Half of
> the code is already there.
Right, but we’d need to add the XPath validation.
So we’d be modeling ALL of the configuration, including constraints, not just
the trivial syntax.
> 1. OpenWRT already has a JSON RPC implementation - you can access the data,
> change it and execute various additional actions such as reload, etc.
> 2. How to express using json yang modelled data is an RFC
You’re talking about 7951 or something else? I think that’s the latest…
Haven’t checked the Draft IDEA’s.
> 3. There is a draft to move it around over JSON-RPC (disclaimer - I am one of
> the co-authors of the draft and the co-authors of the OpenDaylight plugin
> which implements the specification).
> What is missing is either:
> Option A: Implement the OpenWRT side presentation to match the draft using
> the existing infra.
For SoHo uses, which is probably the biggest segment of Openwrt users, this is
probably the best.
> Option B: Do not do anything in OpenWRT and use an off-router translation
> layer which implements a translation to draft-json-rpc or translation to
> I have had Option B enqueued for quite a while, just cannot grab a timeslot
> to do it. It will of course be better to do option A and do it properly.
>> For certain things, UCI is a bit limiting in terms of what sort of
>> configuration state you can express.
>> Especially if there are multiple levels of nesting.
>> And yes, I realize I just contradicted myself: I’m advocating for more
>> powerful configurations which *couldn’t* then be re-exported back into UCI.
>> Maybe it’s worth abandoning UCI altogether?
>> Or having an import script which ingests and converts your UCI and then
>> deletes it?
>> Don’t know. These seem like the sort of questions to be looked at during a
>> GSoC project.
openwrt-devel mailing list