test, pasta: Ignore deprecated addresses in tests

[dgibson]

The default_addr shell function in test/system/helpers.network is used to get the host's default address, which is used in a number of pasta networking tests. However, in certain circumstances it can incorrectly pick a deprecated address as the primary address. Correct it to exclude those.

Does this PR introduce a user-facing change?

No

[giuseppe]

LGTM

[sbrivio-rh]

LGTM

Reviewed-by: Stefano Brivio <sbrivio@redhat.com

[Luap99]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dgibson, giuseppe, Luap99

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [Luap99,giuseppe]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[edsantiago]

This got merged before I had a chance to review. I think it's broken, and blowing up:

[+1968s] not ok 615 [505] pasta/bridge and host.containers.internal
...
<+032ms> # $ podman run --rm --network=bridge quay.io/libpod/testimage:20240123 grep host.containers.internal /etc/hosts
<+581ms> # [ rc=1 ]
         # #/vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
         # #|     FAIL: pasta ip must the only one one the host (bridge)
         # #| expected: 10.128.15.24010.88.0.1
         # #|   actual: 10.128.15.240
         # #\^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

See https://cirrus-ci.com/build/5129923445129216 but look ONLY at sys tests. This is a known-broken PR. Lots of failures are expected, but pasta failures are not.

[dgibson]

This got merged before I had a chance to review. I think it's broken, and blowing up:

[+1968s] not ok 615 [505] pasta/bridge and host.containers.internal
...
<+032ms> # $ podman run --rm --network=bridge quay.io/libpod/testimage:20240123 grep host.containers.internal /etc/hosts
<+581ms> # [ rc=1 ]
         # #/vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
         # #|     FAIL: pasta ip must the only one one the host (bridge)
         # #| expected: 10.128.15.24010.88.0.1

Huh. Looks like the host has 2 valid IPs that got concatenated here. .. but I'm not sure how that could happen with the jq script I had :/. Can you get the output of ip -j -4 addr show on the host in question?

     # #|   actual: 10.128.15.240
     # #\^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

See https://cirrus-ci.com/build/5129923445129216 but look _ONLY_ at `sys` tests. This is a known-broken PR. Lots of failures are expected, but pasta failures are not.

[edsantiago]

Added to #22782, results will be ready in about 50 minutes (1500Z)

[edsantiago]

Also, I have no idea if this has anything to do with your PR. I'm operating solely on post hoc ergo propter hoc logic.

[dgibson]

Huh. I think this is actually related to PR #22740 which added this new test.

[Luap99]

But this PR passed tests so and is rebased to contain the test from #22740 which passed looking at the logs, I think the error is introduced in your PR (although it is likely a issue with the test not handling the second ip correctly)

[dgibson]

But this PR passed tests so and is rebased to contain the test from #22740 which passed looking at the logs, I think the error is introduced in your PR (although it is likely a issue with the test not handling the second ip correctly)

I can't see how my patch could introduce this problem, though. The bogus looking expected value is not coming from the default_addr function I altered, but from hostname -I.

[Luap99]

But this PR passed tests so and is rebased to contain the test from #22740 which passed looking at the logs, I think the error is introduced in your PR (although it is likely a issue with the test not handling the second ip correctly)

I can't see how my patch could introduce this problem, though. The bogus looking expected value is not coming from the default_addr function I altered, but from hostname -I.

Sorry I meant you (@edsantiago) not you (@dgibson), so yes I agree this PR is fine and did not cause a regression.

[edsantiago]

#22782 passed CI, so the bug must be in my registry PR. I am sorry for causing undue concern.