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/.
Neels Hofmeyr nhofmeyr at sysmocom.deI welcome a solution like this very much. However, it wouldn't be a real solution to the human vs machine interaction issue. There are a lot of cans of worms hidden in this problem space and our status quo. The notion that we should only use the CTRL interface for automated interaction sounds like a good idea, but is quite impractical IMO. For TTCN3 tests or at congress, for example, it is so simple to just interact with the VTY instead of first implementing CTRL commands that do the same thing (and merging patches and so on), and the CTRL also has some problems in its protocol design... So in my own opinion / daily practice, I have kind of let go of this notion that the VTY is for humans only. What you are proposing is an interesting solution for structured input into a program, but there is no easy way for *querying* structured information from a program's VTY existing implementation in that way. We can't only expose those VTY items that don't return any output (we have no way to distinguish those -- so we also can't easily translate GET and SET to VTY commands), so this will probably just return the same vty_out() as a VTY command would print, only on CTRL. That kind of obsoletes the CTRL interface, might as well just use the VTY, if it returns the same output anyway. Related to that is the lack of structure in the VTY: we don't formally compose a response and send it, instead we vty_out() maybe N times, maybe not... We'd have to redirect the vty_out() to CTRL somehow. There's also the question of receiving larger responses, think a list of subscribers -- so far CTRL clients expect the entire response in one read(). I'm not entirely sure whether it is a fundamental flaw in the CTRL implementation, but AFAIR I have often looked at CTRL clients and found a lack of structuring there, on a protocol level. It would certainly be a problem if a multi-packet response by accident had a "GET_REPLY" at the start of a subsequent packet. We don't properly escape response content... Doing both input and querying properly would IMO mean a lot of re-implementing. Every now and then I thought a bit about maybe implementing an object model where a command returns certain named values / lists thereof, and the VTY is then a renderer to put those into human readable formats, while the CTRL would return those values raw in a nicely parseable way (a bit like SQL responses). But that would also mean quite a lot of more effort to implement a VTY command compared to the simple C-code and vty_out() we use now. (let alone re-implementing every VTY command we have so far.) In the end I so far mostly conclude that it is too much effort to rewrite the entire VTY, and that it is simplest / most practical to actually ignore the CTRL interface completely, also for machine interaction :/ ~N On Tue, Feb 16, 2021 at 04:23:12PM +0100, Harald Welte wrote: > 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) -- - Neels Hofmeyr <nhofmeyr at sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Harald Welte