Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

test/system: For pasta port forwarding tests don't bind socat server #24064

Merged
merged 1 commit into from
Sep 26, 2024

Conversation

dgibson
Copy link
Collaborator

@dgibson dgibson commented Sep 25, 2024

The various pasta port forwarding tests run a socat server inside a container, then connect to it from a socat client on the host. Currently we have the server bind to the same specific address within the container as we connect to on the host.

That's not quite what we want. For "tap" tests where the traffic goes over pasta's L2 link to the container it's fine, though unnecessary. For "loopback" tests where traffic is forwarded by pasta at the L4 socket level, however, it's not quite right. In this case the address used is either 127.0.0.1 or ::. That's correct and as needed for the host side address we're connecting to. However on the container side, this only works because of an odd and arguably undesirable behaviour of pasta: we use the fact that we have an L4 socket within the container to make such "spliced" L4 connections appear as if they come from loopback within the container. A container will generally expect it's loopback address to be only accessible from within the container, and this odd behaviour may be changed in pasta in future.

In any case, the binding of the container side server is unnecessary, so simply remove it.

Link: #24045

Does this PR introduce a user-facing change?

No.

The various pasta port forwarding tests run a socat server inside a
container, then connect to it from a socat client on the host.  Currently
we have the server bind to the same specific address within the container
as we connect to on the host.

That's not quite what we want.  For "tap" tests where the traffic goes over
pasta's L2 link to the container it's fine, though unnecessary.  For
"loopback" tests where traffic is forwarded by pasta at the L4 socket
level, however, it's not quite right.  In this case the address used is
either 127.0.0.1 or ::.  That's correct and as needed for the host side
address we're connecting to.  However on the container side, this only
works because of an odd and arguably undesirable behaviour of pasta: we use
the fact that we have an L4 socket within the container to make such
"spliced" L4 connections appear as if they come from loopback within the
container.  A container will generally expect it's loopback address to be
only accessible from within the container, and this odd behaviour may be
changed in pasta in future.

In any case, the binding of the container side server is unnecessary, so
simply remove it.

Link: containers#24045

Signed-off-by: David Gibson <[email protected]>
@openshift-ci openshift-ci bot added the do-not-merge/release-note-label-needed Enforce release-note requirement, even if just None label Sep 25, 2024
@dgibson
Copy link
Collaborator Author

dgibson commented Sep 25, 2024

/cc @Luap99 @sbrivio-rh @adelton

@openshift-ci openshift-ci bot requested review from Luap99 and sbrivio-rh September 25, 2024 04:49
Copy link
Contributor

openshift-ci bot commented Sep 25, 2024

@dgibson: GitHub didn't allow me to request PR reviews from the following users: adelton.

Note that only containers members and repo collaborators can review this PR, and authors cannot review their own PRs.

In response to this:

/cc @Luap99 @sbrivio-rh @adelton

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

@openshift-ci openshift-ci bot added release-note-none and removed do-not-merge/release-note-label-needed Enforce release-note requirement, even if just None labels Sep 25, 2024
@dgibson dgibson self-assigned this Sep 25, 2024
@dgibson dgibson added pasta pasta(1) bugs or features and removed release-note-none labels Sep 25, 2024
Copy link
Member

@Luap99 Luap99 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Contributor

openshift-ci bot commented Sep 25, 2024

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dgibson, 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:

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

@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Sep 25, 2024
@sbrivio-rh
Copy link
Collaborator

Well, again, this didn't work by mistake: I purposefully bound socat's sockets here to check exactly this behaviour as I intended it.

Anyway, it makes sense to change it, of course, and we'll need this to be merged in Podman before we can merge the change for #24045 in passt, so (assuming it does something):

LGTM

@dgibson
Copy link
Collaborator Author

dgibson commented Sep 26, 2024

Well, again, this didn't work by mistake: I purposefully bound socat's sockets here to check exactly this behaviour as I intended it.

Ok, that wasn't actually obvious to me. I assumed it had been copied from the equivalent logic in the passt test suite, and that that had been copied from the outbound cases which bind to 127.0.0.1 for arguably different reasons.

Anyway, it makes sense to change it, of course, and we'll need this to be merged in Podman before we can merge the change for #24045 in passt, so (assuming it does something):

LGTM

@Luap99
Copy link
Member

Luap99 commented Sep 26, 2024

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Sep 26, 2024
@openshift-merge-bot openshift-merge-bot bot merged commit 76a9321 into containers:main Sep 26, 2024
56 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. pasta pasta(1) bugs or features
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants