Thoughts on a next generation MIB/VTY replacement

historical

On Thu, Mar 09, 2017 at 02:08:23AM +0100, Harald Welte wrote:
> And rather than adding all the missing bits and pieces with hand-crafted
> code to the control interface, we should have a generic way to define a
> new configuration value, and that value should then be automatically
> parse- and storable via VTY as well as a programmatic interface.

+1

> "stall" the main application by performing I/O intensive operation on
> the VTY

I once used a script that connects to nitb's vty, prints the lchan summary and
exits. I ran that once a second. It often managed to crash the NITB! ... I
never actually investigated it, but would have been good to do so.

> Remembering the port numbers is clumsy.  It would be more convenient if
> a single command line interface could provide access to the
> configuration and the state of multiple different processes / network
> elements.
[...]
> 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.

So would the central interface simply remember the port numbers for us? No,
you're talking about a "config server" that the individual applications connect
to. On the one hand nice, on the other yet another osmo-entity. Still, +1.

Would osmo-programs require the config server to run?
Would they be able to launch the config daemon automatically -- portably?

> GET SET NOTIFY
> ENUM, integers with ranges, etc.
> machine-parseable description of a "MIB/config item", together with
> syntax, ranges, enum values, help texts, etc (ideally in the C source
> code, possibly in comments?)

Add to the wishlist: an indicator whether changing the value immediately
changes the application's behavior. A boolean unfortunately doesn't cut it,
e.g. some settings take effect when a specific BTS' OML link is restarted.
It could have the values "yes, immediate", "no, needs restart" and "please see
comment" with a separate comment provided for humans.

With global structs like gsm_network, I could imagine a completely automagic
code generation from API comments. The description could contain the global
gsm_network instance's symbol name, and the machine built code could provide
the NITB's side as well as the config server's side, in the NITB storing those
values directly in the global gsm_network instance. Or maybe let the automagic
code create a replacement for the config part of the gsm_network struct. That's
all easy for singleton items.

The default NOTIFY could invoke a simple GET (sometimes storing a value in a
struct is enough to change behavior immediately), but a manual on_notify() can
be specified (presence of on_notify() doesn't guarantee immediate effect).

More complex would be things like fetching a subscriber with a given IMSI first
and applying changes there. Arbitrary complexity of actions to update a value
are thinkable, so we probably won't get around writing it manually? Semi?

But hold on, there are different cases: we don't want to store individual IMSIs
in the config server (that's what the HLR is for), while we do want to store
individual BTS configurations centrally.

For GET/SET/NOTIFY of a BTS element, we would need the API to have an array
index argument, analogous to 'bts 0', 'bts 1'. For 'trx 0' etc we even need
nested array indexes. With a path scheme? GET('bts[2].trx[0].arfcn').

But for operations on a subscriber, we would instead merely send instructions
to the HLR to do/store/say things -- if we want to allow managing subscribers
from the central "vty" application, and if we want to allow querying the
current state of entities (like 'show lchan summary'), we need another class of
items that don't GET/SET things from/to the central config server, but tell an
application to do or say something. Call them COMMAND, and they would feature
arbitrary arguments. In the VTY we just implemented whatever we want to
happen, in this scheme we should explicitly differentiate config items from
commands.

When we have separated BSC from NITB for good, centrally issued COMMANDs could
also make up for the removed information match-up: in the NITB we always knew
which BTS a subscriber was calling from with all of the detailed BTS state.
With a separate BSC we don't anymore -- but the central "vty" could run queries
with MSC and BSC to match up that information conveniently again.

> All of this is brainstorming and vaporware

It would be nice to dabble up some hacky code to discuss about, to sharpen our
teeth on; without spending too much time on it and having in mind to discard it
for something better anytime?

Sounds a bit like re-inventing dbus. (I don't know much about dbus though,
would it make sense to use dbus?? Is it a giant kraken of dependencies?)

Seems to me that with all the wishlist features we have collected now, the
implementation of such a system would actually be quite complex and not a small
effort.

I think the most important feature is that all our config items become a
machine and human API at the same time -- and that is a killer feature for all
those folks asking for web interfaces.

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170309/94e0855b/attachment.bin>