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