> On Feb 13, 2018, at 11:12 AM, Anton Ivanov <anton.iva...@cambridgegreys.com> 
> wrote:
> 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 
> netconf.
> 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.



> A.
>> 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.
>> -Philip
openwrt-devel mailing list

Reply via email to