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

Reply via email to