You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now Podman machines on Windows publish 2 named pipes - one Podman specific and another one Docker compatible (if it is available). Named pipes are still the go to way for exposing non TCP connections under Windows, but as AF_UNIX (https://devblogs.microsoft.com/commandline/af_unix-comes-to-windows/) support has become a more commonly used feature on Windows it would be useful to add this as well. Curl tool bundled with Windows can access UNIX sockets, so, the examples from API docs would become relevant for Windows users and it will allow writing different sorts of automation using shell scripting + curl tool.
Suggest potential solution
Add publishing of additional endpoint to gvproxy and win-sshproxy command lines, the transport is already supported need to only add the command line arguments.
According to this https://endoflife.date/windows it could potentially cause issues for still supported Win 10 1507 and Win 10 1607, as all other still supported builds has its baseline above 17063 (the introduction of AF_UNIX) to Windows. I think it would be already an issue to have Podman machines running on such old Windows builds.
In case if it still considered necessary to support environments w/o AF_UNIX this could be put behind feature toggle added to settings, but this feature toggle would become less and less relevant going forward and as this change will not land before 5.3.0 it might not be reasonable to support very old OS versions with edge version of Podman.
Have you considered any alternatives?
Continue to publish only named pipes, which could be used for automation and use podman machine ssh to use curl to access API (which is less convenient, but would work for many cases).
Additional context
No response
The text was updated successfully, but these errors were encountered:
Feature request description
Right now Podman machines on Windows publish 2 named pipes - one Podman specific and another one Docker compatible (if it is available). Named pipes are still the go to way for exposing non TCP connections under Windows, but as AF_UNIX (https://devblogs.microsoft.com/commandline/af_unix-comes-to-windows/) support has become a more commonly used feature on Windows it would be useful to add this as well. Curl tool bundled with Windows can access UNIX sockets, so, the examples from API docs would become relevant for Windows users and it will allow writing different sorts of automation using shell scripting + curl tool.
Suggest potential solution
Add publishing of additional endpoint to gvproxy and win-sshproxy command lines, the transport is already supported need to only add the command line arguments.
According to this https://endoflife.date/windows it could potentially cause issues for still supported Win 10 1507 and Win 10 1607, as all other still supported builds has its baseline above 17063 (the introduction of AF_UNIX) to Windows. I think it would be already an issue to have Podman machines running on such old Windows builds.
In case if it still considered necessary to support environments w/o AF_UNIX this could be put behind feature toggle added to settings, but this feature toggle would become less and less relevant going forward and as this change will not land before 5.3.0 it might not be reasonable to support very old OS versions with edge version of Podman.
Have you considered any alternatives?
Continue to publish only named pipes, which could be used for automation and use
podman machine ssh
to use curl to access API (which is less convenient, but would work for many cases).Additional context
No response
The text was updated successfully, but these errors were encountered: