HEADS UP: stricter VTY, possible config fallout

Neels Hofmeyr nhofmeyr at sysmocom.de
Thu Sep 21 16:44:23 UTC 2017


On Thu, Sep 21, 2017 at 01:44:02PM +0200, Pablo Neira Ayuso wrote:
> But it would be good to keep in the horizon to have a more stricter
> policy on breaking backward compatibility, even if there are good
> reason to fix up inconsistent things, or fix in new software, eg.
> osmo-bsc while keeping the current behaviour around in the legacy
> openbsc.git tree.

Yes, I mentioned this idea in the patch submission: to be able to pass a flag
to the VTY to enable or disable the new indentation bound behavior. The patch
was accepted without it, but I would still favor such an implementation. It
would be logical if I did this, but I have a multitude of tasks for the current
change to the new repositories. Not sure if sysmocom would fund that, given
that the focus is on the new repositories.

As a workaround, it is always possible to use a libosmocore without the VTY
patches:

git clone git://git.osmocom.org/libosmocore
cd libosmocore
git revert 430636328c2fbd9fffc0eac5114462c200b7f2cb 4a31ffa2f0097d96201f80305a0495c57552f0ad

Another workaround would be to not update the OsmoNITB installations on running
systems. After all, our intention is to not spend time on new implementations
for the old openbsc repository.

The reason why we are doing these things now is that it is a good thing to
change everything at once, minimizing the effort for users to change over.

Nevertheless, there are various other features that the old OsmoNITB offered,
which we either need to re-implement in the new split way, or which users need
to farewell:
- accept-all policy, entering phone numbers in the HLR automatically for
  arbitrary SIM cards.
- keeping an IMEI[SV] database beyond volatile in-ram subscriber storage.
- introspection of BTS data on the MSC level, i.e. correlate subscribers with
  actual lchans on a specific BTS.
and probably some more.

Do not hesitate to ask about these, be they long discussions or not.  The most
important aspect after all is to keep the community thriving and affirmative
towards Osmocom developments.

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20170921/485cb8c9/attachment.bin>


More information about the osmocom-net-gprs mailing list