RFC: generic CTRL interface for VTY config settings

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Thu Feb 18 01:05:26 UTC 2021


Hi Pau,

On Wed, Feb 17, 2021 at 10:30:25PM +0100, Pau Espin Pedrol wrote:
> >    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
> 
> I'd probably go for this one from all the ones you proposed. This way, you
> keep the usual CTRL structure ("." separating/slitting parameters), while
> you simply add a new character to specify "levels" or "nodes" (as per VTY
> terminology).

ACK.

> The question here is how to define information in code to apply
> getter/setters for CTRL commands...

Not sure I'm following you here?

> Somebody may not like the idea, (and may be not directly related to the
> topic at hand), but perhaps looking at something similar to a REST interface
> which provides json output and which can easily be interacted using python
> or even curl directly.
> REST interface provides already way to provide levels/nodes (URL
> directories)as well as parameters "?foo=bar&hello=bye").
> So using HTTP may not be needed, but it may make sense to reuse some REST
> related ideas, like URLs and json output (with C implementation in 1 file
> like cjson).

CTRL started with the idea that somebody wants to perform basic SNMP
style SET/GET/TRAP operations, but we didn't want to import the
complexity of "Simple" SNMP parsing/encoding/...  in a non-blocking
fashion.  It was never intended to do anything else but setting or
getting a single value in each command, and sending the occasional TRAP.

I do think whatever we do as a next iteration (if any) should center
around that external MIB / configuration store idea.  At that point the osmo-*
program becomes a client to the config store, ideally with transaction/commit/rollback
logic, and anyone can come up with whatever interface they want towards
that config store - if it's not already a well-documented and established
interface to begin with.

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



More information about the OpenBSC mailing list