[OpenWrt-Devel] GSoC 2018 - we are in!

[Philip Prindeville]

> On Feb 13, 2018, at 11:12 AM, Anton Ivanov <anton.ivanov at 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 data.


> 
>> We would probably need bi-directional conversion from YANG to UCI, etc.
> 
> Do you mean yang modeled data?


Yes


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


Agreed.

-Philip


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