Expose Podman named pipe in Inspect output

[arixmkii]

Fixes #16860

PodmanPipe structure added to ConnectionConfig. Named pipe address is not full equivalent of a file, but 1) it can be represented as a UNC path; 2) internally in code it used with os.Stat API similar to files; 3) it is logically to add it with the same shape as PodmanSocket; 4) it is OS specific, but PodmanSocket in the moment of introduction was also OS specific and was present in Windows builds, where it was not used before, I considered that this sort of overhead is acceptable, so, it is modeled with VMFile and unconditionally added.

Additional refactoring was applied to promote some utility functions for named pipe to the machine common part instead of WSL: PipeAvailable and WaitPipeExists. There 100% will be need to use former in QEMU machine, but the latter was just logical to keep next to the former.

Important note - why it is not possible to use PodmanSocket for this purpose. First of all there is no way to communicate transport type with VMFile structure and this would put additional complexity on clients to understand how to use this value. Another reason is that to me it looks desirable to keep PodmanSocket reserved for QEMU machine and unix domain socket to match QEMU on other hosts, but it will still need to expose named pipe, because NodeJS clients (most notable Podman Desktop) can't use unix domain sockets on Windows (because of the lack of support in libuv).

Signed-off-by: Arthur Sengileyev arthur.sengileyev@gmail.com

[NO NEW TESTS NEEDED]

Does this PR introduce a user-facing change?

Machine connection info includes named pipe address on supported hosts

[arixmkii]

Added "[NO NEW TESTS NEEDED]" because I could not figure out any tests for podman machine inspect for either QEMU or WSL. I will update the PR if they are actually needed.

Also, I'm still to test this locally end-to-end with Podman Desktop.

[arixmkii]

"int podman fedora-36 root host Failing after 4m"

It doesn't look like /var/tmp/go/src/github.com/containers/podman/test/e2e/common_test.go:120 has any references to machine code. Also, "int podman fedora-37 root host Successful in 27m" passes. From the title my guess is that they are the same sets just using different hosts. I guess then failed one could be a fluke, but I can later force push rebasing to head of main and see if this helps.

[rhatdan]

LGTM
@n1hility PTAL

[vrothberg]

Restarted the flaked job

[vrothberg]

Is this function really doing what it's supposed to?

It returns true if the path does not exist (and false if it exists) but the name/callers suggest differently.

[arixmkii]

I kept original name. There are 2 different semantics here. Pipe available for bind vs Pipe available for connection. May be it is time to improve the naming if this one is promoted from private to shared. I will take a look later today.

[vrothberg]

Thanks! Yes, that would help me brain parse the code :)

[arixmkii]

Renamed to PipeNameAvailable. Was thinking about PipeAddress, because it is more common (at least from my experience) for everything network/connection like, but MS uses Name it their docs https://learn.microsoft.com/en-us/windows/win32/ipc/pipe-names

PipeNameAvailable doesn't look like a masterpiece of naming, but it at least makes it clear what is actually checked by the function.

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: arixmkii, vrothberg

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 [vrothberg]

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

[arixmkii]

Seems like this was not a fluke. Will try to understand what is wrong with the test. Current guess is that there is some JSON stuff inside, which has to be updated as well.

According to line numbers in error output the failure is inside TestLibpod, which most probably should be unrelated to these changes 🤔

From logs:

[+0154s] Trying to pull registry.fedoraproject.org/fedora-toolbox:36...
[+0154s] Getting image source signatures
[+0154s] Copying blob sha256:cc95ab9e6dd0c919883311faff2e14646bb7b0e8163bd80544db9c92d78892ed
[+0154s] Copying blob sha256:a78a55e65f905f25ca1270b77ebdf41d191a077282259e13d581923ee26cf85e
[+0154s] Error: copying system image from manifest list: writing blob: storing blob to file "/var/tmp/storage2176274141/2": happened during read: unexpected EOF

This doesn't look like something expected. So, if not a fluke, then potentially something with the infra.

[arixmkii]

Just noticed that previous failure was "int podman fedora-36 root host Failing after 4m", but now it is "int podman fedora-36 root container Failing after 6m ", so, this are different failures using some similar versions.

Then probably they are not related to changes in this PR after all.

[vrothberg]

This doesn't look like something expected. So, if not a fluke, then potentially something with the infra.

This is a very stubborn and frequent flake at the moment, sorry for that. I restarted the failed jobs.

[rhatdan]

/lgtm