RFC: generic CTRL interface for VTY config settings

historical

On Tue, Feb 16, 2021 at 05:23:10PM +0100, Neels Hofmeyr wrote:
> I 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.

It is not a *solution*.  The only real solution is https://osmocom.org/issues/1975

> 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 [...]

I would exclude tests here, as
a) tests need to do super strange things at times, like resetting state,
   which never happens in production use
b) tests also want to test the VTY interface itself

> congress, for example, it is so simple to just interact with the VTY instead of
> 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.

It depends on what.  I'm happy with programmatic access to the VTY for simple
operations like changing a certain value (basically, anything below CONFIG_NODE).

I am still fundamentally and very strictly opposed to using the "show" and related
commands from programs, as that is super volatile and breaks every time the output
is formatted differently.

> 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), 

Anything below the config node is not supposed to generate any output -
except in error cases where CMD_WARNING is a clear indicator that
something went wrong.

The "get" part is probably more tricky as we'd have to generate a full
'write terminal' internally and then walk that from the "generic" code

> so this will probably just return the same vty_out() as a VTY command would print, only on

as stated above, this is intended for setting and hopefully getting
single configuration values, nothing else.

> There's also the question of receiving larger responses, think a list of
> subscribers -- 

that also is not the point.  You don't have lists of subscribers below
the config node.

>  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 :/

This proposal is intended as an interim improvement for some use cases,
until we hopefully at some point get to https://osmocom.org/issues/1975

-- 
- 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)