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 almost 3 years 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 almost 3 years ago
- Related to Bug #3215: GGSN_Tests.ttcn GTP-U sequence number handling incompatible with kernel GTP-U added
#3 Updated by laforge over 2 years ago
- Tags set to GTP
#4 Updated by laforge over 2 years ago
- Status changed from In Progress to Stalled
#5 Updated by laforge over 2 years ago
- Priority changed from Urgent to Normal
#6 Updated by laforge 6 days ago
- Assignee changed from laforge to osmith
laforge wrote:
I'm not working with an automatic setup yet, but what I have managed so far is:
[...]
Not sure if I will find those scripts again, I will try.
Meanwhile, I'm convinced that a different approach might be more applicable:- build a very minimal kernel from a user-sepcified git tree (git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git is a good deafult)
- build a initrd containing the kernel modules, osmo-ggsn and the dependencies (I guess network:osmocom:nightly is fine)
- build a libvirt XML description for the qemu-kvm VM that can be used with virsh
- attach that VM to the same network as the ttcn3-ggsn-test conatiner
- execute the TTCN3 test suite like normal, but against the GGSN in the VM, not in the osmo-ggsn-master docker image
In this approach there would be no need for a block storage device at all. The initrd would contain everything needed.
Some useful links- README file on how to build minimal kernels for execution in VM: https://gist.github.com/chrisdone/02e165a0004be33734ac2334f215380e
- ktest (https://github.com/YADRO-KNS/ktest) really sounds like it does most of what we want, is also aimed for integration with jenkins
- seems to focus on building a single out-of-tree module rather than a full kernel
- seems to be targeted to opensuse (not sure how much it matters)
- has zero documentation besides https://ostconf.com/system/attachments/files/000/001/543/original/ktest.pdf?1541150201
- rapido (https://github.com/rapido-linux/rapido) - bunch of shell scripts doing most of the required steps, but meant for human user, not automatization
- video of rapido talk https://media.ccc.de/v/1416-rapido-quick-kernel-testing-from-source/related
#7 Updated by laforge 6 days ago
I would expect the attached .config file to build a kernel with everything we need. It was created by starting with 'allnoconfig' and then manually enabling various features. For sure one could go even smaller than this, but I enabled features which might come in handy at some later point.
