Attention is currently required from: fixeria, laforge.

View Change

1 comment:

Patchset:
- Patch Set #1:
  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.

To view, visit change 38341. To unsubscribe, or for help writing mail filters, visit settings.