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.orgHi Neels,
On Thu, Mar 09, 2017 at 02:41:37PM +0100, Neels Hofmeyr wrote:
> I once used a script that connects to nitb's vty, prints the lchan summary and
> exits. I ran that once a second. It often managed to crash the NITB! ... I
> never actually investigated it, but would have been good to do so.
this should not happen, and I don't see a reason why it would. There's
no concurrency and no race conditions, everything runs synchronously in
one thread. I've not observed such behavior so far (luckily). but it
should be a relatively trivial scriptable test case: "vty load
generation" ;)
> So would the central interface simply remember the port numbers for us? No,
> you're talking about a "config server" that the individual applications connect
> to. On the one hand nice, on the other yet another osmo-entity. Still, +1.
I don't really see where the problem lies with 'yet another process'.
People have been using zebra+quagga for some 20 years by now, and they
always came as a suite of processes. And that was before systemd took
care of re-spawning them ;)
I mean seriously, on my laptop I have 195 kernel threads cluttering my
'ps' output already, why would I care about a hand ful of osmocom
processes?
> Would osmo-programs require the config server to run?
yes.
> Would they be able to launch the config daemon automatically -- portably?
I would probably not bother but simply print a meaningful error message
and assume that people get their systemd rules right in terms of the
dependencies?
> > GET SET NOTIFY
> > ENUM, integers with ranges, etc.
> > machine-parseable description of a "MIB/config item", together with
> > syntax, ranges, enum values, help texts, etc (ideally in the C source
> > code, possibly in comments?)
>
> Add to the wishlist: an indicator whether changing the value immediately
> changes the application's behavior.
We could, but I would rather use such a massive change to do it
properly, i.e. implement the 'immediate reaction' to value changes in
the respective programs.
> A boolean unfortunately doesn't cut it,
> e.g. some settings take effect when a specific BTS' OML link is restarted.
Yes, those are bugs / shortcomings of the code and should be
adressed by people caring sufficiently about it? We can re-generate the
BCCH/SACCH filling at any time and update them in the BTS. We can also
re-configure the OML Managed Objects at runtime. The protoocl permits
all of that.
> With global structs like gsm_network, I could imagine a completely automagic
> code generation from API comments. The description could contain the global
> gsm_network instance's symbol name, and the machine built code could provide
> the NITB's side as well as the config server's side, in the NITB storing those
> values directly in the global gsm_network instance. Or maybe let the automagic
> code create a replacement for the config part of the gsm_network struct. That's
> all easy for singleton items.
Yes, I would go for separate config structs, and hand a newly-allocated
one to the application, so the application can check for differences
between old and new config, if neded, before applying the new config.
> More complex would be things like fetching a subscriber with a given IMSI first
> and applying changes there. Arbitrary complexity of actions to update a value
> are thinkable, so we probably won't get around writing it manually? Semi?
That's not configuration data, is it? I would not try to do subscriber
management within the MIB.
> But hold on, there are different cases: we don't want to store individual IMSIs
> in the config server (that's what the HLR is for), while we do want to store
> individual BTS configurations centrally.
exactly.
> For GET/SET/NOTIFY of a BTS element, we would need the API to have an array
> index argument, analogous to 'bts 0', 'bts 1'. For 'trx 0' etc we even need
> nested array indexes. With a path scheme? GET('bts[2].trx[0].arfcn').
yes. That's one part that OpenWRT's uci does ver nicely, but it has
weak types (or none at all?) and is unsuitable in many other ways.
Also, I think uci has limited path depth, which isn't nice either.
> But for operations on a subscriber, we would instead merely send instructions
> to the HLR to do/store/say things -- if we want to allow managing subscribers
> from the central "vty" application, and if we want to allow querying the
> current state of entities (like 'show lchan summary'), we need another class of
> items that don't GET/SET things from/to the central config server, but tell an
> application to do or say something. Call them COMMAND, and they would feature
> arbitrary arguments. In the VTY we just implemented whatever we want to
> happen, in this scheme we should explicitly differentiate config items from
> commands.
yes. There are many details to be resolved, though. We could simply
require each application to provide pretty-print functions for all of
its 'introspectable structs's and then build a library/plugin that the
"VTY application" can load to print even the "raw" binary structs. We'd
just have to prefix them with some kind of type annotation (in the
protocol, not at runtime in all processes). This way even the printf()
effort is kept out of the respective applications, further reducing load
that adminstrative interfaces can put on them.
> When we have separated BSC from NITB for good, centrally issued COMMANDs could
> also make up for the removed information match-up: in the NITB we always knew
> which BTS a subscriber was calling from with all of the detailed BTS state.
> With a separate BSC we don't anymore -- but the central "vty" could run queries
> with MSC and BSC to match up that information conveniently again.
>
possibly, but that sounds rather more comples.
> > All of this is brainstorming and vaporware
>
> It would be nice to dabble up some hacky code to discuss about, to sharpen our
> teeth on; without spending too much time on it and having in mind to discard it
> for something better anytime?
Yes, but not now [TM]. I at least think I need to spend lots of more
time thinking about this (in the bathtub or elsewhere).
> Sounds a bit like re-inventing dbus. (I don't know much about dbus though,
> would it make sense to use dbus?? Is it a giant kraken of dependencies?)
I don't think dbus is a configuration management system, but an IPC
system. And yes, we'd need some kind of IPC, but I would ignore/defer
the exact IPC method/transport for now, as it is not the key "idea"
under discuission.
> Seems to me that with all the wishlist features we have collected now, the
> implementation of such a system would actually be quite complex and not a small
> effort.
yes. The question is if we can find something that is possible to do in
stages/milestones, rather than changing everything at once. Or some
elegant hack that provide at least some of the features we need at
limited effort.
> I think the most important feature is that all our config items become a
> machine and human API at the same time -- and that is a killer feature for all
> those folks asking for web interfaces.
exactly. Whether we do this still inside the processes or in an external
central process is a minor detail.
Also, what I'd really like is to see the generalized read/parse and save
code, avoiding all the possible manual mistakes we have at places.
Finally, being able to do away with the "vty-additions.xml" files but
having more documentation at the same place where the config items are
defined/declared is better and will make it feasible to have more
documentation in the vty reference manuals.
What I find very surprising is that nobody seems to have come up with
something like this already. But what can be found is miles far away
from what we're thinking of. There's libconfuse, uci, libcli, clish,
... - all of them seem to have some interesting ideas, but fall quite
short of a proper system. And then there's things like SNMP and
net-snmp which are ugly and complex.
The IETF has come up with OpenConfig (and NETCONF and RESTCONF
protocols) which goes very much into the direction I've been thinking
of. But it seems they've mostly been working on architecture as well as
OpenConfig models for regular IP-type network element configuration,
(writtein in YANG, a language they invented for that purpose) and
protocols, but I haven't seen any FOSS implemenataions yet?
http://jedelman.com/home/openconfig-data-models-and-apis/ is a good
intro into this part of the networking universe. Fully buzzword
compatible ;) And again very heavy and complex. If there were many
implementations out there, it might be worth investigating - but there
aren't.
Regards,
Harald
--
- 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)