On 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(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)