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
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
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
Don’t know. These seem like the sort of questions to be looked at during a
On Feb 13, 2018, at 5:10 AM, Andreas Bräu <a...@andi95.de> wrote:
we've been accepted again for Google Summer of Code 2018. To see our
ideas and possible projects, please visit
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
openwrt-devel mailing list
Anton R. Ivanov
Cambridge Greys Limited, England and Wales company No 10273661
openwrt-devel mailing list