Hi.
There's clearly big difference between split BSC/MSC and NITB (config files, support for SCCP-lite etc) which makes the transition rather lengthy.
What about SGSN and related stuff? It's been transitioned to libvlr at the time of split as well, but does this transition have any user-visible consequences?
If not than we could transition gradually: * make SGSN build optional (--enable-gprs?) in openbsc repo * start building OsmoSGSN from osmo-sgsn repo instead of openbsc (both .deb and OE) * test and make sure that it works the same way (both on sysmobts and on debian) * disable SGSN build by default and announce that patches should be made against new repo * remove gprs code from openbsc leaving placeholder readme with the link to new repo
All the steps above are unrelated to BSC/MSC items so it could be done independently.
On Thu, Sep 21, 2017 at 04:36:51PM +0200, Max wrote:
Hi.
On a related note. There's clearly big difference between split BSC/MSC and NITB (config files, support for SCCP-lite etc) which makes the transition rather lengthy.
What about SGSN and related stuff? It's been transitioned to libvlr at the time of split as well, but does this transition have any user-visible consequences?
Slight misunderstanding: no, the SGSN has "always" had GSUP support and is not actually using libvlr. All we did is upgrade the SGSN to be able to do UMTS authentication (Milenage). There was a plan to use libvlr in the SGSN as well, but since the SGSN is now working as it is, we are unlikely to do that.
If not than we could transition gradually:
- make SGSN build optional (--enable-gprs?) in openbsc repo
osmo-sgsn is in its own repository now. Makes no sense to add such config option there.
- start building OsmoSGSN from osmo-sgsn repo instead of openbsc (both .deb and OE)
yes, that is the transition. The BTS and SGSN are notably the most back- and forward compatible components in this transition, there isn't much difference except the M3UA/SCCP addition in the SGSN, which again is only needed for IuPS, i.e. 3G data. IIRC the entire 2G SGSN land is identical between openbsc.git and osmo-sgsn.git. The points needed to transition mostly apply to: BSC, STP, MSC, HLR, MGW.
- test and make sure that it works the same way (both on sysmobts and on debian)
- disable SGSN build by default and announce that patches should be made against new repo
- remove gprs code from openbsc leaving placeholder readme with the link to new repo
The entire openbsc.git repository will cease to be used. We will not remove parts from it, we will basically lay it to rest as a whole.
~N
Hi Neels,
On Thu, Sep 21, 2017 at 08:04:26PM +0200, Neels Hofmeyr wrote:
The entire openbsc.git repository will cease to be used. We will not remove parts from it, we will basically lay it to rest as a whole.
This is unrealistic, as there are people who will likely want to continue to use OsmoNITB for at least some time to come. I'm thinking of Rhizomatica or Fairwaves, for example. Or even various of our 'sysmoBTS starter kit' users until they do a major upgrade to 201705. There still might be the occasional important bug fix that needs to be applied to openbsc.git
My idea would be: In order to avoid anyone to submit patches against the GPRS components in there, I think it makes sense to remove those parts and make sure that we have no two [except for 3G support] identical copies of the SGSN (plus gtphub, plus gb-proxy) code lying around. This will help people who are continuing to use OsmoNITB to get the benefits of newer versions of SGSN & co, without 'accidentially' sticking to old versions.
For the remaining NITB code , there should be a strict policy of first applying any change to OsmoBSC or OsmoMSC, and only then optionally apply it to openbsc.git.
For sure we should still accept at a minimum clear bug fix commits for the NITB. If somebody in the community (or a paying sysmocom customer) wants to maintain even new features going into the NITB, then we should simply bless one such person as the legacy NITB maintainer. The policy remains: New features and fixes must first be applied to BSC/MSC and only then to NITB.
Regards, Harald
FYI, the patch which will move nightly packages to osmo-sgsn and osmo-ggsn repos is available at https://gerrit.osmocom.org/#/c/4056/
On 23.09.2017 06:19, Neels Hofmeyr wrote:
- start building OsmoSGSN from osmo-sgsn repo instead of openbsc (both .deb and OE)
yes, that is the transition. The BTS and SGSN are notably the most back- and forward compatible components in this transition, there isn't much difference except the M3UA/SCCP addition in the SGSN, which again is only needed for IuPS, i.e. 3G data. IIRC the entire 2G SGSN land is identical between openbsc.git and osmo-sgsn.git.
Hi Max,
On Thu, Sep 21, 2017 at 04:36:51PM +0200, Max wrote:
There's clearly big difference between split BSC/MSC and NITB (config files, support for SCCP-lite etc) which makes the transition rather lengthy.
Not necessarily lengthy, but non-trivial, for sure.
What about SGSN and related stuff? It's been transitioned to libvlr at the time of split as well, but does this transition have any user-visible consequences?
I don't think it has been "transitioned to libvlr", has it?
OsmoSGSN has been supporting GSUP for years longer than OsmoMSC, so there's not really any user-visible change/transition, other than that of a different repository. Or am I missing something?
If not than we could transition gradually:
- make SGSN build optional (--enable-gprs?) in openbsc repo
I wouldn't go for that incremental step, but got to removing the code from openbsc.git altogether, like you suggested later in your mail below
- start building OsmoSGSN from osmo-sgsn repo instead of openbsc (both
.deb and OE)
I see no reason why not to.
- disable SGSN build by default and announce that patches should be > made against new repo
- remove gprs code from openbsc leaving placeholder readme with the link to new repo
I would suggest that we do both at once, as the code (aside from file moving/renaming and #include fixups) is exactly the same.
All the steps above are unrelated to BSC/MSC items so it could be done independently.
ACK.
-
Harald Welte -
Max -
Neels Hofmeyr