|
|
# RESTCONF on OpenWRT
|
|
|
|
|
|
This text is an initial input to a discussion about possible
|
|
|
motivations, deployment modes and problems of using RESTCONF for
|
|
|
configuring OpenWRT routers.
|
|
|
|
|
|
## 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
|
|
|
(`/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)
|
|
|
command-line utility. The UCI system than transparently translates
|
|
|
these configuration files into “native” configuration files of a
|
|
|
particular service.
|
|
|
|
|
|
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):
|
|
|
|
|
|
* The flat format of UCI configuration files isn't suitable for
|
|
|
expressing even moderately complex logic and
|
|
|
relationships. Therefore, many services offer hooks that allow for
|
|
|
augmenting UCI data with extra configuration in the native
|
|
|
format. This means that the user needs to learn both UCI and native
|
|
|
configuration.
|
|
|
|
|
|
* The translation of UCI to native formats is only one-way: if the
|
|
|
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:
|
|
|
|
|
|
* Configuration errors are reported to the remote management
|
|
|
application in a form that is not (easily) machine readable, or not
|
|
|
reported at all.
|
|
|
|
|
|
* Acquisition of run-time date from the device involves error-prone
|
|
|
screen scraping.
|
|
|
|
|
|
## Use Cases for RESTCONF
|
|
|
|
|
|
Motivation for managing OpenWRT routers via RESTCONF is essentially
|
|
|
the same as on any other platform:
|
|
|
|
|
|
* Effective and reliable remote management: operations are performed
|
|
|
as RPCs, and returned output or error messages are in a
|
|
|
machine-readable form.
|
|
|
|
|
|
* Possibility of receiving asynchronous notifications with
|
|
|
fine-grained subscription options.
|
|
|
|
|
|
* 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.
|
|
|
|
|
|
## Deployment Options
|
|
|
|
|
|
Three main deployment options may be considered (combinations are
|
|
|
possible, too):
|
|
|
|
|
|
1. Translate RESTCONF data to UCI configurations, and then use the UCI
|
|
|
system essentially unchanged.
|
|
|
|
|
|
1. Replace the UCI layer with RESTCONF, and then use RESTCONF data in
|
|
|
a similar fashion as UCI data are currently being used,
|
|
|
i.e. generate specific daemon or service configuration from them.
|
|
|
|
|
|
1. Use a system like [Sysrepo](http://www.sysrepo.org/) for improving
|
|
|
back-end integration of deamons and services.
|
|
|
|
|
|
## Hardware-Related Considerations
|
|
|
|
|
|
## Available RESTCONF Implementations |