<div dir="auto">Hi Harald,<br><br><div data-smartmail="gmail_signature" dir="auto">A very interesting topic indeed.</div><div class="gmail_extra" dir="auto"><br><div class="gmail_quote">On Mar 9, 2017 4:15 AM, "Harald Welte" <<a href="mailto:laforge@gnumonks.org">laforge@gnumonks.org</a>> wrote:<blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So what I had in mind for quite some time (actually since netconf 1.2<br>
about one year ago), is to have some kind of an external "VTY/MIB<br>
daemon" (or even separate daemons for each) which maintains a<br>
hierarchical database of configuration values.  The MIB deamon simply<br>
offers an API (via client library) to GET or SET the individual values,<br>
or to NOTIFY an application about a changed value.  This API is both<br>
used by the actual Osmocom programs to obtain their configuration (and<br>
obtain updates to it during runtime), as well as by the "VTY daemon"<br>
providing interactive shell access to it.  Finally, other external<br>
applications could use the same interface/client library to do the same.<br>
A proxy to SNMP or REST interfaces can be imagined, for even more<br>
interfacing with the outside world.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Right now VTY and control interface serve three functions:</div><div dir="auto">1. Configuration ("configure terminal")</div><div dir="auto">2. Object manipulation (eg "subscriber IMSI .. active ...")</div><div dir="auto">3. Information query with polling and traps (eg "show ..." and control interface)</div><div dir="auto"><br></div><div dir="auto">A centralized configuration DB massively works with use case (1), but doesn't really fit use cases (2) and (3) IMHO. You can do it, but then it'll serve just as a proxy to the actual application and may become a quite bloated and complicated piece of code.</div><div dir="auto"><br></div><div dir="auto">Running another instance of yet another daemon is also something I personally would really like to avoid looking from a user/admin perspective. Number of processes we're already running on a NITB BTS is already getting out of hand :(</div><div dir="auto"><br></div><div dir="auto">So stealing an idea from FreeSWITCH and building on top of it:</div><div dir="auto"><br></div><div dir="auto">Why don't we keep the configuration DB inside each app, but expose a machine readable API only? Then VTY becomes just one of many applications talking to this API on par with web-ui, scripts and whatnot.</div><div dir="auto"><br></div><div dir="auto">This API could be something like JSON or something more binary (Erlang terms binary format, BERT, etc). We can even make it more REST-like with only GET/SET/NOTIFY or more RPC like with a richer set of primitives. There are pros and cons in all these approaches, but the key point is that:</div><div dir="auto">1. This works with all 3 use cases above</div><div dir="auto">2. It's less intrusive into the current code base (I think)</div><div dir="auto">3. Allows to have a single CLI/VTY app talking to any Osmocom app. Btw, the app can know default ports of standard apps and allow connection by neg let name like:</div><div dir="auto">  $ osmo-cli -n osmo-bts</div><div dir="auto">4. The app can still do TAB completion and help in a VTY way - FreeSWITCH handles this perfectly with its fs_cli.</div><div dir="auto"><br></div><div dir="auto">What do you think? It's a completely different approach than a config DB, so I wanted to through this idea in without too much details to see if it sticks.</div><div dir="auto"><br></div><div dir="auto"><span style="font-family:sans-serif">Please excuse typos. Written with a touchscreen keyboard.</span><br style="font-family:sans-serif"><br style="font-family:sans-serif"><span style="font-family:sans-serif">--</span><br style="font-family:sans-serif"><span style="font-family:sans-serif">Regards,</span><br style="font-family:sans-serif"><span style="font-family:sans-serif">Alexander Chemeris</span><br style="font-family:sans-serif"><span style="font-family:sans-serif">CTO/Founder Fairwaves, Inc.</span><br style="font-family:sans-serif"><span style="font-family:sans-serif"><a href="https://fairwaves.co">https://fairwaves.co</a></span><br></div><div class="gmail_extra" dir="auto"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div></div></div>