Skip to content

Add pesto support for dynamic port forwarding via pasta control socket#755

Open
Honny1 wants to merge 1 commit intocontainers:mainfrom
Honny1:pesto-support
Open

Add pesto support for dynamic port forwarding via pasta control socket#755
Honny1 wants to merge 1 commit intocontainers:mainfrom
Honny1:pesto-support

Conversation

@Honny1
Copy link
Copy Markdown
Member

@Honny1 Honny1 commented Apr 9, 2026

  • Add a pesto client (pesto_linux.go) that invokes the pesto binary to dynamically update pasta's port forwarding table via a UNIX domain socket, enabling rootless bridge containers to add/remove port mappings without restarting pasta.
  • Start pasta with -c <socketPath> to enable the pesto control channel and expose PestoSocketPath in RootlessNetnsInfo.

Fixes: https://redhat.atlassian.net/browse/RUN-2214
Fixes: containers/podman#8193
Fixes: https://redhat.atlassian.net/browse/RUN-3587

This requires the pesto binary, so it requires a version of passt that includes the "Read-only dynamic update implementation" patch series, which has not yet been merged or released. The next passt release after that series lands will be the first to ship pesto.

@github-actions github-actions bot added the common Related to "common" package label Apr 9, 2026
Comment thread common/libnetwork/pasta/pesto_linux.go
@Honny1 Honny1 force-pushed the pesto-support branch 2 times, most recently from ca46ecb to 83c12a5 Compare April 10, 2026 11:31
@Honny1 Honny1 marked this pull request as ready for review April 10, 2026 12:31
}

args := portMappingsToPestoArgs(ports)
args = append(args, socketPath)
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

can socketPath == ""

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

No, it cannot be. It should be checked by the caller. Should I add a check to be sure?

// does NOT perform DNAT to the container. Netavark handles that inside the
// netns. Therefore each mapping uses HostPort as both source and destination
// (e.g. "-t 0.0.0.0/8080") so traffic arrives at the port netavark expects.
func portMappingsToPestoArgs(ports []types.PortMapping) []string {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

does this func make sense if ports is empty? i think you will get something in args that is not expected?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

I think this makes sense. If no ports are specified, it will set -t none -u none, meaning no ports will be forwarded.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

common Related to "common" package

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Alternate port_handler that keeps the source ip for user-defined rootless networks

3 participants