On Thu, Mar 09, 2017 at 10:20:11PM +0300, Alexander Chemeris wrote:
Right now VTY and control interface serve three functions:
- Configuration ("configure terminal")
- Object manipulation (eg "subscriber IMSI .. active ...")
- 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?