-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
WSL machine - consider adding pipe address to machine inspect output #16860
Comments
The most simple implementation - just adding it to output reusing all the available methods in the same file is pretty straightforward. The one which involves moving it to machine config structure is a more significant refactoring. |
A friendly reminder that this issue had no activity for 30 days. |
Still valid. There should be a way to communicate API listening interface address w/o guessing on the client side. |
Did some experiments and due to lack of AF_UNIX support on Windows in nodejs nodejs/node#35008 it is better to extend the structure to expose 2 different endpoints - one for Unix socket and one for named pipe. And then Expected result would look like:
|
Care to open a PR to make this happen? |
@rhatdan I will work on this. And after this one is finalized (reviewed and accepted) will submit a fix to Podman Desktop as well. |
Great thanks. |
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind feature
Description
Currently pipe address of WSL machine is not published anywhere (it is built using the way one could read in code or documentation), but it would be better to allow this to be retrievable using some interface. There is ConnectionInfo with PodmanSocket path in it, but it is not used by WSL. Code here.
If it is used then naming will be a bit confusing (as one may argue that pipe in not a 100% socket), but it will allow some more flexibility. For example Podman Desktop instead of "guessing" here the pipe address will just read using podman cli (like it already does reading list of machines).
This will also simplify things for alternative implementations (like QEMU machine #13006) as they will not have to mimic this behavior or Podman Desktop would need to become aware that alternative implementations exist.
Steps to reproduce the issue:
Describe the results you received:
Outputs null
Describe the results you expected:
Outputs pipe address
Additional information you deem important (e.g. issue happens only occasionally):
Output of
podman version
:Output of
podman info
:Package info (e.g. output of
rpm -q podman
orapt list podman
orbrew info podman
):Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide?
Yes (including built from sources)
Additional environment details (AWS, VirtualBox, physical, etc.):
WSL machine
The text was updated successfully, but these errors were encountered: