Cellular Network Infrastructure

A version indication could also make a program behave differently by default,
without actual config item values changing their defaults.

For example, in osmo-bsc, we have a special case that when there are no
neighbors configured, all cells are each others' neighbors. It would have made
things simpler to implement for inter-BSC/-MSC handover, if it had been
possible to remove that feature. We could have required that the new neighbor
configuration config needs at least 'defaults v1.3', and that from that point
on we no longer make all cells neighbors.

In that light maybe 'version' is better, more general term.

We could add the 'defaults' cmd in a generic fashion in libosmocore, with the
application just providing the list of valid versions apart from "v0"? Then it
is up to each application to introduce new default behavior.

BTW, this could also address a long standing PITA: that our logging allows so
many format tweaks, which are chosen in a peculiar way by default, which users
sometimes provide and then there's e.g. the logging level missing or the source
path is messing up the vertical alignment... And we could adjust the default
startup logging levels.
So instead of all of us copying log config fragments, we could agree on our
common denominator and run a nice log from an empty config file.

On Wed, Nov 01, 2023 at 01:49:00AM +0000, neels wrote:

So how about a general mechanism in all of our config files in form of a vty command, maybe like this:

osmo-foo.cfg:

> defaults (v0|v1.5|v1.6)
> 

so a user can decide when to make the cfg upgrade, independently from binary upgrades.

I personally don't think it's worth the effort of building this (ant
maintaining it!). We don't really even know historically which software
version had what exact defaults, and creating that (even just for today)
and maintaining it in the future looks very time-consuming and
error-prone to me.

On Wed, Nov 01, 2023 at 04:15:14PM +0000, laforge wrote:

We don't really even know historically which software
version had what exact defaults

Yes yes totally agree, I did not have in mind to add every single version we
have. I would have only 'v0' now, and add only very specific versions when
needed. Because so far, we've always added compat shims.

Where it would be cool to have this in general is the already complex logging
system that we can only make even more complex at the moment to solve daily
itches. Thinking of some specific pet peeve of mine... =)

But I agree that it isn't all that important, just a neat idea i think, because
so far I thought there is no way around it short of libosmocore v2.0.

for the record, an example:
If I wanted to remove the 'allow-tmsi 0' default from osmo-hnbgw, then I add a
"v1.5.1" to hnbgw for the next release.
'show defaults' would then list
v0
v1.5.1
(could be just v1, v2, ... but i thought it'd be nice to correlate to a
release number)
That would just remain the same until something new shows up.
When installing the new hnbgw, the log would show a NOTICE that a new set of
defaults is available by setting 'defaults v1.5.1'.
We could even allow the user to provide any version number, and we use the
latest available entry before that, by some strcmp.