Podman6: Vendor update w/o CNI + additional cleanups

[lsm5]

Checklist

Ensure you have completed the following checklist for your pull request to be reviewed:

• Certify you wrote the patch or otherwise have the right to pass it on as an open-source patch by signing all
  commits. (git commit -s). (If needed, use git commit -s --amend). The author email must match
  the sign-off email address. See CONTRIBUTING.md
  for more information.
• Referenced issues using Fixes: #00000 in commit message (if applicable)
• Tests have been added/updated (or no tests are needed)
• Documentation has been updated (or no documentation changes are needed)
• All commits pass make validatepr (format/lint checks)
• Release note entered in the section below (or None if no user-facing changes)

Does this PR introduce a user-facing change?

None

Depends on containers/container-libs#412 and containers/buildah#6453

[packit-as-a-service]

[NON-BLOCKING] Packit jobs failed. @containers/packit-build please check. Everyone else, feel free to ignore.

[lsm5]

@containers/podman-maintainers PTAL. Will keep in draft until buildah and container-libs PRs are merged (see description for links).

[Luap99]

Looks like the compose tests are failing here. I don't think it is related to your cni removal though so likely another container -libs change

[Luap99]

compose failure is reproduced using podman main with container-libs main so ignore that for your work

$ go get go.podman.io/storage@main && go get go.podman.io/image/v5@main &&  go get go.podman.io/common@main && make vendor && make binaries

$ ./test/compose/test-compose ipam
...
Error response from daemon: IPAM error: requested ip address 10.123.0.253 is already allocated to container ID 5715be599bbbe0eb0b647273a2532835e13448421edc651ee45b00b62751d8ad

@Honny1 I think that might be related to your multiple static ip work, can you look into this?

[Honny1]

Let me check that.

[Honny1]

Compat API adds the IP address twice.

podman/pkg/api/handlers/compat/containers_create.go

Lines 349 to 367 in faa9b02

	// if IP address is provided
	if endpoint.IPAddress.IsValid() {
	staticIP := net.IP(endpoint.IPAddress.AsSlice())
	netOpts.StaticIPs = append(netOpts.StaticIPs, staticIP)
	}
	if endpoint.IPAMConfig != nil {
	// if IPAMConfig.IPv4Address is provided
	if endpoint.IPAMConfig.IPv4Address.IsValid() {
	staticIP := net.IP(endpoint.IPAMConfig.IPv4Address.AsSlice())
	netOpts.StaticIPs = append(netOpts.StaticIPs, staticIP)
	}
	// if IPAMConfig.IPv6Address is provided
	if endpoint.IPAMConfig.IPv6Address.IsValid() {
	staticIP := net.IP(endpoint.IPAMConfig.IPv6Address.AsSlice())
	netOpts.StaticIPs = append(netOpts.StaticIPs, staticIP)
	}
	}

I need to check Docker documentation on how it should be handled. I will address that with #27775.

[Luap99]

I need to check Docker documentation on how it should be handled. I will address that with #27775.

I think likely one setting is preferred over the other? In general I guess a simple fix could be to deduplicate the slice with slices.Sort followed slices.Compact on the ips otherwise?

[Honny1]

I need to check Docker documentation on how it should be handled. I will address that with #27775.

I think likely one setting is preferred over the other? In general I guess a simple fix could be to deduplicate the slice with slices.Sort followed slices.Compact on the ips otherwise?

Deduplication is a possibility.

---

I found that endpoint.IPAddress represents operational state; from what I've seen in the Docker code, it isn't used for configuration. I still need to verify this through testing Docker. So maybe we should match that behavor but it is a breaking change.

[Luap99]

So maybe we should match that behavor but it is a breaking change.

This is docker API, anything docker does not do we have always been very open to just break to make it behave like docker.

[lsm5]

I guess the machine-linux podman fedora-43-aarch64 rootless host test is also dependent on docker API? It's also failing on #27775

[Luap99]

machine-linux podman fedora-43-aarch64 rootless host

That is a timeout out that is flaking everywhere, I hope #28299 improves the situation for it.

[Luap99]

practically speaking that cli flag also is used by netavark, though sure if there are no known users of this config right now I am good dropping it fully

[Luap99]

maybe we should do that commit elsewhere

While I agree removing the numbers makes sense it means it breaks all existing links. i.e. anyone linking to the headers https://github.com/containers/podman/blob/main/troubleshooting.md#1-variety-of-issues---validate-version

I think we should keep the numbers because of that, I think we can drop this entry and just skip the number 29. Generally I am not opposed to drop the numbers but lets not do this as part of cni removal PR here so we can get some more people to chime in on such a change

[lsm5]

sgtm. Reverted and dropped number 29. This as well as the docs/source/locale/ja updates (also for slirp) could be in separate PRs.

[Luap99]

does is not true AFAICT

podman build --isolation && --arch runs as e2e test as remote just fine?

What is the exact error here, I would not object skipping on remote if it is a true cannot be supported on remote but the --isolation flag does not seem to be the reason.

[lsm5]

my bad, you're right, --isolation as a flag works fine on remote. The issue is the second part of the test added in containers/buildah#6697 which uses the BUILDAH_ISOLATION env var:

BUILDAH_ISOLATION=chroot run_buildah 125 build --network=none $WITH_POLICY_JSON ${TEST_SCRATCH_DIR}
expect_output --substring "cannot set --network other than host with --isolation chroot"

The BUILDAH_ISOLATION env var is not propagated to the server via podman-remote. On remote, line 124 in cmd/podman/common/build.go resets the isolation default to "", so the env var silently has no effect:

// Unset the isolation default as we never want to send this over the API
// as it can be wrong (root vs rootless).
_ = flags.Lookup("isolation").Value.Set("")

Here's the exact behavior difference:

# Local podman - works correctly:
$ BUILDAH_ISOLATION=chroot ./bin/podman build --network=none /dev/null
Error: cannot set --network other than host with --isolation chroot

# podman-remote - env var silently ignored, wrong error:
$ BUILDAH_ISOLATION=chroot ./bin/podman-remote build --network=none /dev/null
Error: context must be a directory: "/dev/null"

The test expects "cannot set --network other than host with --isolation chroot" but on remote it never gets that error because the env var has no effect. Updated the skip reason to "BUILDAH_ISOLATION env var not propagated via podman-remote" to be precise.