Thoughts on a next generation MIB/VTY replacement

historical

Hi Harald,

A very interesting topic indeed.

On Mar 9, 2017 4:15 AM, "Harald Welte" <laforge at gnumonks.org> wrote:

So what I had in mind for quite some time (actually since netconf 1.2
about one year ago), is to have some kind of an external "VTY/MIB
daemon" (or even separate daemons for each) which maintains a
hierarchical database of configuration values.  The MIB deamon simply
offers an API (via client library) to GET or SET the individual values,
or to NOTIFY an application about a changed value.  This API is both
used by the actual Osmocom programs to obtain their configuration (and
obtain updates to it during runtime), as well as by the "VTY daemon"
providing interactive shell access to it.  Finally, other external
applications could use the same interface/client library to do the same.
A proxy to SNMP or REST interfaces can be imagined, for even more
interfacing with the outside world.

Right now VTY and control interface serve three functions:
1. Configuration ("configure terminal")
2. Object manipulation (eg "subscriber IMSI .. active ...")
3. Information query with polling and traps (eg "show ..." and control
interface)

A centralized configuration DB massively works with use case (1), but
doesn't really fit use cases (2) and (3) IMHO. You can do it, but then
it'll serve just as a proxy to the actual application and may become a
quite bloated and complicated piece of code.

Running another instance of yet another daemon is also something I
personally would really like to avoid looking from a user/admin
perspective. Number of processes we're already running on a NITB BTS is
already getting out of hand :(

So stealing an idea from FreeSWITCH and building on top of it:

Why don't we keep the configuration DB inside each app, but expose a
machine readable API only? Then VTY becomes just one of many applications
talking to this API on par with web-ui, scripts and whatnot.

This API could be something like JSON or something more binary (Erlang
terms binary format, BERT, etc). We can even make it more REST-like with
only GET/SET/NOTIFY or more RPC like with a richer set of primitives. There
are pros and cons in all these approaches, but the key point is that:
1. This works with all 3 use cases above
2. It's less intrusive into the current code base (I think)
3. Allows to have a single CLI/VTY app talking to any Osmocom app. Btw, the
app can know default ports of standard apps and allow connection by neg let
name like:
  $ osmo-cli -n osmo-bts
4. The app can still do TAB completion and help in a VTY way - FreeSWITCH
handles this perfectly with its fs_cli.

What do you think? It's a completely different approach than a config DB,
so I wanted to through this idea in without too much details to see if it
sticks.

Please excuse typos. Written with a touchscreen keyboard.

--
Regards,
Alexander Chemeris
CTO/Founder Fairwaves, Inc.
https://fairwaves.co
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170309/5f238118/attachment.htm>