Bug #3208
automatic test setup for OsmoGGSN with kernel-gtp-u
10%
Description
We do have some tests in GGSN_Tests.ttcn which are executed at https://jenkins.osmocom.org/jenkins/job/ttcn3-ggsn-test/
However, this runs osmo-ggsn only in userspace mode, i.e. we're not testing the interaction with kernel-gtp-u.
Let's create a setup in which we can test with [various version of the] kernel gtp-u module. I guess this would then mean we're running some qemu-kvm VM with a given kernel + distribution, in which we're running a specified version of osmo-ggsn.
Turning the VM into a jenkins build slave is not a good idea, as that would mean it's not possible to build + restart a different kernel as needed. So we should rather have something like a build slave which then (inside a jenkins job) starts the VM with OsmoGGSN, possibly after rebuilding kernel and/or osmo-ggsn.
Related issues
History
#1 Updated by laforge about 1 year ago
- Status changed from New to In Progress
- % Done changed from 0 to 10
- script to create a qumu-kvm VM with Debian 9 and all required packages, plus the libmnl, libgtpnl and osmo-ggsn source code
- another script to
- build a given [newer] Linux kernel version on the host, followed by
scpthe resulting kernel+modules into the running VM and- using
update-grubto activate the new kernel [only works if new version is higher]
This setup can then be used to run GGSN_Tests.ttcn against it.
#2 Updated by laforge about 1 year ago
- Related to Bug #3215: GGSN_Tests.ttcn GTP-U sequence number handling incompatible with kernel GTP-U added
#3 Updated by laforge about 1 year ago
- Tags set to GTP
