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.orgOn Thu, Mar 09, 2017 at 10:20:11PM +0300, Alexander Chemeris wrote:
> Right now VTY and control interface serve three functions:
> 1. Configuration ("configure terminal")
> 2. Object manipulation (eg "subscriber IMSI .. active ...")
> 3. Information query with polling and traps (eg "show ..." and control
> interface)
> 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.
I have some vague ideas here but need to think further about it before I
think it's ready for an actual proposal.
> 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 :(
I don't see the problem. On modern systems it is simply a matter of a
systemd job configuring that daemon as a dependency for the other
daemons. And if you prefer some other system like upstart, it is
basically the same. I don't think any user cares about the number of
processes, at least not until you're talking about hundreds of them.
> 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.
It's another idea, indeed. I guess to a large extent the same work is
required for both my or your proposal: You need some data structures
that describe the syntax of the configuration values, their permitted
ranges, types, help texts, etc. The difference is then just where this
configuration is stored / "owned". I like the idea to have it external,
as some paramters can then easily be shared between processes. Let's
say the 'gsm_network' configuration, i.e. things like MCC, MNC. You
curently have to enter that on both the SGSN and the MSC, but this could
be stored just as one 'network' config object that multiple processes
refer to.
> 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.
Well, see above, I think it's more or less the same code, but running
inside the same process vs. running it externaly?
--
- 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)