... | ... | @@ -2,13 +2,13 @@ |
|
|
|
|
|
This text is an initial input to a discussion about possible
|
|
|
motivations, deployment modes and problems of using RESTCONF for
|
|
|
configuring OpenWRT routers.
|
|
|
configuring and managing OpenWRT routers.
|
|
|
|
|
|
[RESTCONF](https://tools.ietf.org/html/draft-ietf-netconf-restconf-18)
|
|
|
is a configuration and management that is based on similar principles
|
|
|
as its [NETCONF](https://datatracker.ietf.org/doc/rfc6241/)
|
|
|
is a configuration and management protocol that is based on similar
|
|
|
principles as its [NETCONF](https://datatracker.ietf.org/doc/rfc6241/)
|
|
|
predecessor but uses HTTP methods for client-server communication
|
|
|
rather special RPC message layer. RESTCONF also permits several
|
|
|
rather than a special RPC message layer. RESTCONF also permits several
|
|
|
alternative data encodings/media types (XML, JSON, CBOR), whereas
|
|
|
NETCONF is only limited to XML.
|
|
|
|
... | ... | @@ -18,8 +18,8 @@ language that is usable with both RESTCONF and NETCONF. |
|
|
## Current Situation
|
|
|
|
|
|
The canonical way of configuring OpenWRT routers is through the
|
|
|
Unified Configuration Interface (UCI). Its main aim is to keep all
|
|
|
user-accessible configuration files in a central location
|
|
|
Unified Configuration Interface (UCI). Its main aim of UCI is to keep
|
|
|
all user-accessible configuration files in a central location
|
|
|
(`/etc/config`) and unify their format. Users are supposed to modify
|
|
|
these configuration files either in a text editor or by using the
|
|
|
[uci](https://wiki.openwrt.org/doc/uci#command_line_utility)
|
... | ... | @@ -31,8 +31,8 @@ From the perspective of a non-geek user, UCI is certainly an |
|
|
improvement over a traditional Unix/Linux systems where configuration
|
|
|
files have daemon- or service-specific locations and a use a host of
|
|
|
different formats. Nevertheless, every serious OpenWRT user will
|
|
|
sooner or later run into the following problems (which are, in fact,
|
|
|
correlated):
|
|
|
sooner or later run into the following problems and limitations (which
|
|
|
are, in fact, correlated):
|
|
|
|
|
|
* The flat format of UCI configuration files isn't suitable for
|
|
|
expressing even moderately complex logic and
|
... | ... | @@ -45,8 +45,10 @@ correlated): |
|
|
native files are directly modified, then UCI gets out of sync and
|
|
|
may later overwrite new data with the old configuration.
|
|
|
|
|
|
Remote configuration scripts can be used with tools like Ansible of
|
|
|
Puppet. However, drawbacks of this approach are well known:
|
|
|
Remote configuration scripts can be used with tools like
|
|
|
[Ansible](https://www.ansible.com/) or
|
|
|
[Puppet](https://puppet.com/). However, drawbacks of this approach are
|
|
|
well known:
|
|
|
|
|
|
* Configuration errors are reported to the remote management
|
|
|
application in a form that is not (easily) machine readable, or not
|
... | ... | @@ -70,7 +72,7 @@ the same as on any other platform: |
|
|
* Use of standard data models that are being developed in IETF and
|
|
|
other SDOs (IEEE, Broadband Forum). This is especially useful in
|
|
|
non-homogeneous networks, provided that all devices support RESTCONF
|
|
|
and implement the data models.
|
|
|
and implement the same data models.
|
|
|
|
|
|
A number of YANG modules that already are (or will soon be) published
|
|
|
as RFCs may be potentially useful for OpenWRT routers. A
|
... | ... | @@ -92,22 +94,21 @@ possible, too): |
|
|
using a database.
|
|
|
|
|
|
1. Use a system like [Sysrepo](http://www.sysrepo.org/) for improving
|
|
|
back-end integration of deamons and services.
|
|
|
back-end integration of daemons and services.
|
|
|
|
|
|
The first option is relatively light-weight in that it doesn't change
|
|
|
anything in OpenWRT itself, just adds an extra configuration layer. It
|
|
|
could be used only for configuration as there is in general no easy
|
|
|
way for translating state data emitted by daemons into the format
|
|
|
that's expected by standard models.
|
|
|
|
|
|
On the other hand, the extra layer added by option #1 increases the
|
|
|
complexity of the whole system and, since the flow of data is still
|
|
|
only in one direction, it just amplifies the problems of UCI mentioned
|
|
|
above. For example, if an admin directly edits a generated UCI file,
|
|
|
this change won't be reflected in RESTCONF configuration. Whilst
|
|
|
the conversion of RESTCONF to UCI is most likely doable, the reverse
|
|
|
conversion and synchronization of both configuration sources seems
|
|
|
next to impossible.
|
|
|
that's expected by standard models. On the other hand, the extra layer
|
|
|
added by option #1 increases the complexity of the whole system and,
|
|
|
since the flow of data is still only in one direction, it just
|
|
|
amplifies the problems of UCI mentioned above. For example, if an
|
|
|
admin directly edits a generated UCI file, this change won't be
|
|
|
reflected in RESTCONF configuration. Whilst the conversion of RESTCONF
|
|
|
to UCI is most likely doable, the reverse conversion and
|
|
|
synchronization of both configuration sources seems next to
|
|
|
impossible.
|
|
|
|
|
|
Option #2 essentially means substituting UCI with RESTCONF data. The
|
|
|
pros and cons of this approach are similar to those of the UCI system.
|
... | ... | @@ -141,8 +142,9 @@ the RESTCONF API, i.e. no manual editing of UCI files can be |
|
|
permitted).
|
|
|
|
|
|
Options #2 and #3 not only mean significantly more development work
|
|
|
but, arguably, they would not be OpenWRT anymore given that the UCI
|
|
|
system is regarded as OpenWRT's flagship.
|
|
|
but, arguably, they would lead to something that cannot be called
|
|
|
OpenWRT anymore given that the UCI system is regarded as OpenWRT's
|
|
|
flagship.
|
|
|
|
|
|
Regarding RESTCONF clients (remote management programs), two variants
|
|
|
are worth considering:
|
... | ... | @@ -157,7 +159,7 @@ are worth considering: |
|
|
|
|
|
The former option would be a user-friendly interface intended for
|
|
|
remote management of a single router (or few, at most) while the
|
|
|
letter would be more suitable for operators of large networks, and
|
|
|
latter would be more suitable for operators of large networks, and
|
|
|
require deeper technical expertise.
|
|
|
|
|
|
It is also worth noting that neither of the open-source RESTCONF
|
... | ... | |