Attention is currently required from: fixeria, laforge.
osmith has posted comments on this change by osmith. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38341?usp=email )
Change subject: ggsn: testenv: run SUT on bridge instead of lo ......................................................................
Patch Set 1:
(1 comment)
Patchset:
PS1:
I didn't like the complexity and overhead of a dockerized setup.
Me neither, especially with having lots of docker containers that need to be built and having duplicated configs that get out of sync. That's why I wrote the testenv script (OS#6494).
I'm not sure if the testenv basis will change much in that regard.
It is much simpler in several ways: * only one container instead of several * using the container is optional * no duplicate configs that get out of sync (like https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38021) * for most Osmocom programs, we only need a simple testenv.cfg and osmo-$program.cfg file, for example: https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38267
All this overhead with qeum virtual machines still seems like a work-around to understanding the real problem to me...
This is not a workaround. QEMU is required to test the kernel GTP-U feature of osmo-ggsn with different kernels as it was previously implemented in docker-playground (OS#3208).
The configs for the GGSN testsuite are by far the most complex, because we run it in all of these combinations (already in docker-playground, I just ported it to testenv here and made it more generic in the process by using osmo-config-merge etc.): * osmo-ggsn + {all,v4_only,v4_only,v4v6_only} APNs * osmo-ggsn with kernel GTP-U (needs QEMU) + {v4_only,v4_only,v4v6_only} APNs * open5gs
When I develop a patch for any of our osmocom projcets, I'm always end up running all tests suites locally / natively / directly on my machine.
OK, that seems to answer that my assumption was wrong: "I'm assuming that people aren't really running osmo-ggsn directly with the testsuite with these configs".
I'll change the patch so the configs have 127.0.0.x again, so this still works as expected.