Hi.
With the ongoing split of OpenBSC into per-project repository, I wonder if we could do the same to OpenGGSN and split libgtp into separate repository?
Rationale:
* would simplify docs for newcomers (it's not obvious that openggsn have to be built ahead of OsmoSGSN because of libgtp)
* simplify release process (we can release libgtp independently of OpenGGSN, makes it easier to automate too)
While at it and considering recent IPv6 support (and related config changes) it might be also good idea to rename it to OsmoGGSN (and libosmo-gtp?) to clearly mark the breaking point.
What do you think?
Hi Max,
On Mon, Aug 28, 2017 at 02:25:48PM +0200, Max wrote:
With the ongoing split of OpenBSC into per-project repository, I wonder if we could do the same to OpenGGSN and split libgtp into separate repository?
Interesting proposal, I don't really have an existing opionion on it.
- would simplify docs for newcomers (it's not obvious that openggsn have to be built
ahead of OsmoSGSN because of libgtp)
Not so sure if that would really simplify it. What would be a good idea is an explicit --{enable-disable}-gtp for old openbsc.git and an unconditional dependency from the new osmo-sgsn.git repository to avoid the "silently built without SGSN support" behavior.
The configure script could also state that 'libgtp is missing... install it from openggsn' or the like.
There are considerable infrastructural changes for libgtp pending: * the list/hashtable of PDP contexts / TEIDs is still global, and not per GSN * the outer (transport) layer is still IPv4 only * the kernel GTP-U support should become part of libgtp, not specific to OpenGGSN
There is currently nobody funding related work or otherwise contributing to it, so this is just a wishlist without any clear target date for implementation.
- simplify release process (we can release libgtp independently of OpenGGSN, makes it
easier to automate too)
I'm not sure if that's a simplification, though?
While at it and considering recent IPv6 support (and related config changes) it might be also good idea to rename it to OsmoGGSN (and libosmo-gtp?) to clearly mark the breaking point.
The osmo-sgsn rename is something I've been pondering in the laforge/osmo-sgsn branch where the VTY is introduced. I've almost decided against it meanwhile, given that > 90% of the code still is OpenGGSN code, and credit belongs to the creators of that and not to Osmocom.
Also, from an User point-of-view, it will be a different program. All recipes, manuals, wiki pages, etc. will need updates. But then, they will need updates due to the vty / config file changes anyway, so it might actually be better to have a new name since it "feels" completely different with VTY and related configuration than the old OpenGGSN.
So in summary: * libgtp split: I'm not entirely sure if at all. If, then we should postpone the first release of that library until changes have been made. * rename: I'm more in favor again, but my opinion seems to change ever week ;)
What do others think?
On 31.08.2017 13:56, Harald Welte wrote:
Not so sure if that would really simplify it. What would be a good idea is an explicit --{enable-disable}-gtp for old openbsc.git and an unconditional dependency from the new osmo-sgsn.git repository to avoid the "silently built without SGSN support" behavior.
From the point of release automation - it certainly would: right now we treat each
repo either as a library or as a non-library project. This allows us to generate meaningful changelogs and check for things like missing API/ABI libversion bump.
Supporting both in the same repo would make helper code much more complex. AFAIK OpenGGSN is the only Osmocom project which produces both library and non-library packages.
The osmo-sgsn rename is something I've been pondering in the laforge/osmo-sgsn branch where the VTY is introduced. I've almost decided against it meanwhile, given that > 90% of the code still is OpenGGSN code, and credit belongs to the creators of that and not to Osmocom.
Also, from an User point-of-view, it will be a different program. All recipes, manuals, wiki pages, etc. will need updates. But then, they will need updates due to the vty / config file changes anyway, so it might actually be better to have a new name since it "feels" completely different with VTY and related configuration than the old OpenGGSN.
I think people tend to associate program's name more with how it "feels like" to work with it rather than who wrote it. At least I do.
On Fri, Sep 01, 2017 at 05:01:14PM +0200, Max wrote:
On 31.08.2017 13:56, Harald Welte wrote:
Not so sure if that would really simplify it. What would be a good idea is an explicit --{enable-disable}-gtp for old openbsc.git and an unconditional dependency from the new osmo-sgsn.git repository to avoid the "silently built without SGSN support" behavior.
From the point of release automation - it certainly would: right now we treat each repo either as a library or as a non-library project. This allows us to generate meaningful changelogs and check for things like missing API/ABI libversion bump.
Supporting both in the same repo would make helper code much more complex. AFAIK OpenGGSN is the only Osmocom project which produces both library and non-library packages.
* We have the osmo-hnbgw program being installed from the "library project" osmo-iuh (or is it a program project also installing libosmo-ranap?); * we have the osmo-stp program coming from libosmo-sccp; * we now have osmo-mgw.git installing both the osmo-bsc_mgcp program as well as libosmo-legacy-mgcp (to-be osmo-mgw and libosmo-mgcp); * libosmocore installs osmo-auc-gen... and I'm fairly sure we can find more mixed library/program instances.
If we really require to strictly treat git trees as *either* library *or* program project, we would need to do a lot more splitting. It seems to me that we unfortunately rather should have more complex helpers instead.
I'll soon bump the new osmo-{msc,bsc,mgw,sgsn} repositories to version 2.0.0, so I need to look at the new release process anyway. Let me comment on that in a separate mail. I hope that I will thus gain a better understanding of the difference or complexity from mixing libraries with programs. (https://osmocom.org/projects/cellular-infrastructure/wiki/Make_a_new_release) I still want some more tweaks to go into the new repositories before bumping, but can review releasing now as good as any other time.
The osmo-sgsn rename is something I've been pondering in the laforge/osmo-sgsn
* I assume typo: osmo-ggsn
branch where the VTY is introduced. I've almost decided against it meanwhile, given that > 90% of the code still is OpenGGSN code, and credit belongs to the creators of that and not to Osmocom.
If we are the sole maintainers now, it makes sense to embed openggsn in our naming scheme of osmo-* and libosmo-*, especially when openbsc.git is gone. We should still credit the origins in README and/or header comments of course.
There is some sense in separating lib(osmo-)gtp from the GGSN, i.e. that building osmo-sgsn only needs the GTP lib and not the GGSN binary. But I have listed numerous similar instances above, so no real reason to split.
IOW, install libosmo-gtp and osmo-ggsn from a joint osmo-ggsn.git. But I'm unsure about: if we rename libgtp to libosmo-gtp, do we confuse the hell out of the rest of the world? So far I found 'libgtp' confusing ("is it osmocom??").
In any case, this now is an ideal time to do renames like this, while we're busy rejiggering half the core network anyway. It will just be part of the new way that everyone needs to adjust to.
~N
Hi Neels,
On Sat, Sep 02, 2017 at 01:29:27AM +0200, Neels Hofmeyr wrote:
If we really require to strictly treat git trees as *either* library *or* program project, we would need to do a lot more splitting. It seems to me that we unfortunately rather should have more complex helpers instead.
ACK. I also don't see why users should have to deal with even more repositories just so that the maintainer can have simpler scripts.
I'll soon bump the new osmo-{msc,bsc,mgw,sgsn} repositories to version 2.0.0, so I need to look at the new release process anyway. Let me comment on that in a separate mail. I hope that I will thus gain a better understanding of the difference or complexity from mixing libraries with programs. (https://osmocom.org/projects/cellular-infrastructure/wiki/Make_a_new_release) I still want some more tweaks to go into the new repositories before bumping, but can review releasing now as good as any other time.
You could also do a 1.99.0 before as an exercise :)
The osmo-sgsn rename is something I've been pondering in the laforge/osmo-sgsn
- I assume typo: osmo-ggsn
branch where the VTY is introduced. I've almost decided against it meanwhile, given that > 90% of the code still is OpenGGSN code, and credit belongs to the creators of that and not to Osmocom.
If we are the sole maintainers now, it makes sense to embed openggsn in our naming scheme of osmo-* and libosmo-*, especially when openbsc.git is gone. We should still credit the origins in README and/or header comments of course.
Ok, then let's aim for that.
There is some sense in separating lib(osmo-)gtp from the GGSN, i.e. that building osmo-sgsn only needs the GTP lib and not the GGSN binary. But I have listed numerous similar instances above, so no real reason to split.
I agree, no split (for now).
IOW, install libosmo-gtp and osmo-ggsn from a joint osmo-ggsn.git. But I'm unsure about: if we rename libgtp to libosmo-gtp, do we confuse the hell out of the rest of the world? So far I found 'libgtp' confusing ("is it osmocom??").
well, we didn't reinvent the wheel where it wasn't required (such as libgtp and libsmpp34).
In any case, this now is an ideal time to do renames like this, while we're busy rejiggering half the core network anyway. It will just be part of the new way that everyone needs to adjust to.
I would time a rename with the introduction of significant user-visible changes.
For the GGSN, this is when the VTY is introduced (ggsn binary to osmo-ggsn, which is already in a branch and could be merged any day.
For libgtp, I would time this with introducing all the API/ABI breakage needed for maintaining pdp contexts per GSN and for supporting IPv6 transport layer addresses. This has currently not been a priority, though :/
Regards, Harald
On Sat, Sep 02, 2017 at 10:24:17AM +0200, Harald Welte wrote:
You could also do a 1.99.0 before as an exercise :)
yep, 1.inf.0 :)
I would time a rename with the introduction of significant user-visible changes.
For the GGSN, this is when the VTY is introduced (ggsn binary to osmo-ggsn, which is already in a branch and could be merged any day.
For libgtp, I would time this with introducing all the API/ABI breakage needed for maintaining pdp contexts per GSN and for supporting IPv6 transport layer addresses. This has currently not been a priority, though :/
Sounds sane to me. So osmo-ggsn soonish, libosmo-gtp probably some other time.
It still does make sense to me to time the osmo-ggsn change within our switch towards the new repositories and AoIP world, so that users get the new way in one go. Meaning let's announce openbsc.git as legacy after that rename.
~N
osmocom-net-gprs@lists.osmocom.org
-
Harald Welte -
Max -
Neels Hofmeyr