chore: integ tests always wait for pipelined

[nstng]

Signed-off-by: Nils Semmelrock nils.semmelrock@tngtech.com

Summary

This change tries to tackle multiple issues. The main idea is to not fetch the current datapath during static initialization of the s1ap_utils, but in the constructor when an object is created.

Tackling #14068

• Moving get_dapatath to the constructor of the s1ap_utils makes it possible to wait (before the s1ap_utils are initialized) for pipelined to actually initialize a datapath
• this should mitigate issues described in [LTE Integ Flakiness] Error when getting Datapath: Get_flows: _ovs_api_request('POST', url, data=data)[datapath] KeyError #14068
• for this the initialization of the s1ap_utils needs to be moved after the magmad_util is initialized (holds the functionality to wait for the start of pipelined)

Working towards enabling again an ipv6 tests that was disable in #14682

• With the s1ap_utils initalization moved after initializing magmad_util we can check if nat is not enabled - and enabling it in this case (this can happen if a test that run with disabled nat failed with an error that prevents the re-enabling of nat in the teardown).
• If a test with disabled nat tries to call pipelined, then we see 6h workflow timeouts in ci.

Tackling #14699

• This is basically the main issue that tracks the two issues above.

Failures in re-runs of tests that re-initialize the datapath

• I have not seen this problem in recent logs - but iirc then we have seen issues where the current datapath id was not the expected id
• hypothesis: a test fails and the datapath is re-initialized - but the s1ap_util does not fetch the id again (because this happens during the static initialization)
• moving the datapath id fetch to the constructor should help with this issue

Test Plan

executed precommit and extended tests locally

Additional Information

Closes #14699
Closes #14068

• This change is backwards-breaking

[github-actions]

Thanks for opening a PR! 💯

A couple initial guidelines

• All commits must be signed off. This is enforced by PR DCO check.
• All PR titles must follow the semantic commits format. This is enforced by Semantic PR.

Howto

• Reviews. The "Reviewers" listed for this PR are the Magma maintainers who will shepherd it.
• Checks. All required CI checks must pass before merge.
• Merge. Once approved and passing CI checks, use the ready2merge label to indicate the maintainers can merge your PR.

More info

Please take a moment to read through the Magma project's

• Contributing Conventions for norms around contributed code

If this is your first Magma PR, also consider reading

• Developer Onboarding for onboarding as a new Magma developer
• Development Workflow for guidance on your first pull request
• CI Checks for points of contact for failing or flaky CI checks
• GitHub-to-Slack mappings for Magma maintainers for guidance on how to contact maintainers on Slack

[github-actions]

Oops! Looks like you failed the AGW Build & Format Python.

Howto

• Instructions on running the formatter and linter locally are provided in the format AGW doc
• Guide to the different CI checks and resolution guidelines

♻️ Updated: ✅ The check is passing the AGW Build & Format Python after the last commit.

[github-actions]

FeG Lint & Test

    2 files  203 suites   40s ⏱️
374 tests 374 ✔️ 0 💤 0 ❌
388 runs  388 ✔️ 0 💤 0 ❌

Results for commit f41698a.

♻️ This comment has been updated with latest results.

[github-actions]

DP Lint & Test

14 tests   14 ✔️  3m 20s ⏱️
  1 suites    0 💤
  1 files      0 ❌

Results for commit f41698a.

♻️ This comment has been updated with latest results.

[mpfirrmann]

Just for my understanding: we would explicitly enable NAT by default for all tests (if of course not disabled during execution) but this would be mainly to counteract failing non-NAT tests?

[nstng]

Just for my understanding: we would explicitly enable NAT by default for all tests (if of course not disabled during execution) but this would be mainly to counteract failing non-NAT tests?

Correct, the current state (before this change) is that NAT is enabled by default. But if a non-NAT test fails hard, i.e., NAT is not enabled again in the test tear down, then the next test start also with non-NAT. (Actually one could argue, that we then could remove the tear down steps in all non-NAT test, but I would leave them because switching the NAT mode takes some time, i.e., we should try to avoid this at test start time).