RFC: generic CTRL interface for VTY config settings

[Harald Welte]

Dear all,

we always had said the VTY is a human CLI, while the CTRL interface is for
interfacing with other software.  This was primarily related to asking users
to not parse the VTY output of "show" commands or the like.  For configuration
via VTY, we have to provide a stable interface anyway, as otherwise loading
config files would not be possible across [non-major] software upgrades.

While that is right in principle, the fact that we don't have a generic configuration
store / API / MIB means that one would explicitly have to add CTRL command for all relevant
settings, which may have been realistic in 2010, but is unrealistic with the hundreds of
VTY configuration parameters today.

I was thinking wither it might make sense to add a generic CTRL interface GET/SET
for "configuration" mode VTY settings.  This would mean we write code once,
and immediately expose all our VTY nodes to CTRL.

Thinking of the following example done via VTY:

-----------------------------------
OsmoBSC> enable 
OsmoBSC# configure terminal 
OsmoBSC(config)# network 
OsmoBSC(config-net)# bts 0
OsmoBSC(config-net-bts)# trx 1
OsmoBSC(config-net-bts-trx)# timeslot 0
OsmoBSC(config-net-bts-trx-ts)# training_sequence_code 3
-----------------------------------

We could have something like the following CTRL command:

SET network.bts.0.trx.1.timeslot.0.training_sequence_code 3

The devil is a bit in the details of the syntax

* the normal '.' as separator looks generally OK, I think we have [almost?] no
  VTY commands that include a ','

* we somehow need some kind of separator to tell where individual VTY commands are
  separated, like

  SET network."bts 0"."trx 1"."timeslot 0".training_sequence_code 3
or
  SET network|bts.0|trx.1|timeslot.0|training_sequence_code 3
or
  SET network#bts.0#trx.1#timeslot.0#training_sequence_code 3
or
  SET network.bts#0.trx#1.timeslot#0.training_sequence_code 3
  SET network.bts at 0.trx@1.timeslot at 0.training_sequence_code 3

I think the last examples would be more "natural" for existing CTRL interface code,
as the dot separat separates tokens, and we simply expand the '#' or '@' to spaces in
the context of VTY commands

The generic vty-cfg-via-CTRL code then would basically emulate a user entering
the sequence of commands - including the "exclusion" of not allowing multiple concurrent
VTY or vty-cfg-via-CTRL users at the same time

What do you guys think?

Regards,
	Harald

-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)