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

[Anton Ivanov]

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.

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

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

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

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.

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
>
>
>> On Feb 13, 2018, at 5:10 AM, Andreas Bräu <ab at andi95.de> wrote:
>>
>> Hi there,
>>
>> we've been accepted again for Google Summer of Code 2018. To see our
>> ideas and possible projects, please visit
>> https://projects.freifunk.net/#/projects
>>
>> What is Google Summer of Code?
>>
>> "Google Summer of Code is a global program focused on bringing more
>> student developers into open source software development. Students work
>> with an open source organization on a 3 month programming project during
>> their break from school."
>>
>> If you're student and interested this program, please get in touch with
>> us or our mentors.
>>
>> See also: https://summerofcode.withgoogle.com/organ…/4687947786354688/
>>
>> BTW: It's still possible to submit your own ideas! To do so, please
>> submit a pull request at
>> https://github.com/freifunk/projects.freifunk.net-contents
>>
>> Thanks,
>>
>> Andi
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


-- 
Anton R. Ivanov

Cambridge Greys Limited, England and Wales company No 10273661
http://www.cambridgegreys.com/
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel