Crc: Podman support for Windows

Created on 10 Mar 2020 · 28Comments · Source: code-ready/crc

Follow-up task to #961 specifically to handle the Windows situation. There are two issues here:

The redistributable of podman-remote.exe is currently only available for them msi and not the zip archive. Since we do not prefer to install or run an external tool to unarchive, we would like this to be corrected.
At the moment using podman-remote on Windows targetting a VM running Fedora 30+ on Hyper-V shows ni problems. But, when using the same podman-remote client with the CRC vm on Hyper-V will result in an unexpected EOF. Running this setup on libvirt or hyperkit shows no problems.

kinbug owindows prioritmajor sizM

Source

gbraad

All 28 comments

In reference to 1; see

https://github.com/containers/libpod/issues/5477 Upstream issue
@jwhonce is looking into this
https://github.com/code-ready/crc/issues/961#issuecomment-594913942

In reference to 2; see:

https://github.com/containers/libpod/issues/5440 Upstream issue
https://github.com/code-ready/crc/issues/961#issuecomment-595658906 debug info using Fedora 30 (works)
https://github.com/code-ready/crc/issues/961#issuecomment-595661000 debug info from CRC VM (fails)

gbraad on 10 Mar 2020

After this is handled, we can revert: #1073 https://github.com/code-ready/crc/commit/09f2e0aac65f084cc5ca5397d10cf6e51686dc76

gbraad on 10 Mar 2020

PS C:\Users\gbraad\.crc\bin> $Env:PODMAN_USER = "core"
PS C:\Users\gbraad\.crc\bin> $Env:PODMAN_HOST = "172.28.191.5"
PS C:\Users\gbraad\.crc\bin> $Env:PODMAN_IDENTITY_FILE = "C:\Users\gbraad\.crc\machines\crc\id_rsa"
PS C:\Users\gbraad\.crc\bin> $Env:PODMAN_IGNORE_HOSTS = "1"
PS C:\Users\gbraad\.crc\bin> .\podman-remote-windows.exe --identity-file $env:PODMAN_IDENTITY_FILE --username $env:PODMAN_USER --remote-host $env:PODMAN_HOST info
client:
  Connection: ssh -p 22 -T -i C:\Users\gbraad\.crc\machines\crc\id_rsa -q -o StrictHostKeyChecking=no
    -o UserKnownHostsFile=/dev/null [email protected] -- varlink -A 'podman --log-level=debug
    varlink $VARLINK_ADDRESS' bridge
  Connection Type: BridgeConnection
  OS Arch: windows/amd64
  Podman Version: 1.8.1-dev
  RemoteAPI Version: 1
host:
  arch: amd64
  buildah_version: 1.12.0-dev
  cpus: 4
  distribution:
    distribution: '"rhcos"'
    version: "4.3"
  eventlogger: journald
  hostname: crc-jccc5-master-0
  kernel: 4.18.0-147.3.1.el8_1.x86_64
  mem_free: 11740884992
  mem_total: 12289851392
  os: linux
  swap_free: 0
  swap_total: 0
  uptime: 7m 10.28s
registries:
  blocked: null
  insecure: null
  search: null
store:
  containers: 0
  graph_driver_name: overlay
  graph_driver_options: |-
    map[overlay.mount_program:map[Executable:/usr/bin/fuse-overlayfs Package:fuse-overlayfs-0.4.1-1.module+el8.1.0+4081+b29780af.x86_64 Version:fuse-overlayfs: version 0.4.1
    FUSE library version 3.2.1
    using FUSE kernel interface version 7.26]]
  graph_root: /var/home/core/.local/share/containers/storage
  graph_status:
    backing_filesystem: xfs
    native_overlay_diff: "false"
    supports_d_type: "true"
  images: 0
  run_root: /run/user/1000

gbraad on 12 Mar 2020

While the issue is 'fixed' and a release is posted at: https://github.com/containers/libpod/releases/tag/v1.8.2 it does not help, as this releasing method is inconsistent with the other platforms. Either ALL platforms on github releases or from the google storage API.

gbraad on 23 Mar 2020

@rhatdan we still have issues with the release location. It is inconsistent between platforms

gbraad on 23 Mar 2020

Where would you like to pick up the releases?

rhatdan on 23 Mar 2020

Google storage is what is used now... it would mean the code does not need
to change. But if you have a release policy for Github, we are willing to
modify the code. As long as this is consistent for all.

gbraad on 23 Mar 2020

I would love to have those binary released as part of github release/tag location for those binary atm not matter but should be consistent so we can regenerate our bundles with same tag without worry about any change in the binaries.

praveenkumar on 23 Mar 2020

👍1

I think we are releasing the windows one there now, so adding mac version makes sense. Linux versions are released in distros, so I don't see us doing it there.

If you guys want to open a PR to help, that would be appreciated.

@baude PTAL

rhatdan on 23 Mar 2020

We can not rely on distro releases for Linux. We also already agreed that
in the original issue this would not be the wisest of choices:
https://github.com/code-ready/crc/issues/961#issuecomment-584100122 and
https://github.com/code-ready/crc/issues/961#issuecomment-584462166 With a
tagged release for linux, macOS and Windows we guarantee support and
feature expectations. For a distro release we can not do this. This is also
the case why we do not rely on the oc binary to be provided by the
distro. Note that the user is always able to override this anyway if needed.

On Mon, Mar 23, 2020 at 10:41 PM Daniel J Walsh notifications@github.com
wrote:

I think we are releasing the windows one there now, so adding mac version
makes sense. Linux versions are released in distros, so I don't see us
doing it there.

If you guys want to open a PR to help, that would be appreciated.

@baude https://github.com/baude PTAL

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/code-ready/crc/issues/1083#issuecomment-602637288,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAAOZVJHLL2C7SEF6L7R4DRI5YI5ANCNFSM4LEZHTSQ
.

Gerard Braad | http://gbraad.nl
[ Doing Open Source Matters ]

gbraad on 23 Mar 2020

👍1

This would mean we would need a static version of the remote client. The upstream work is going on to unify the client and server, but I think we would need to have the ability to continue to build a podman-remote for the linux use case.
@baude @mheon @jwhonce WDYT?

rhatdan on 23 Mar 2020

We originally did not target to support Linux (only macOS and Windows) with
this... but Linux got added as it was easy and possible. The thinking was
that not all platforms might be on par with features or the release of
podman. This is however a different issue ... and maybe we should not offer
this on Linux?

On Tue, Mar 24, 2020 at 1:26 AM Daniel J Walsh notifications@github.com
wrote:

This would mean we would need a static version of the remote client. The
upstream work is going on to unify the client and server, but I think we
would need to have the ability to continue to build a podman-remote for the
linux use case.
@baude https://github.com/baude @mheon https://github.com/mheon
@jwhonce https://github.com/jwhonce WDYT?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/code-ready/crc/issues/1083#issuecomment-602743460,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAAOZRZWX5A5SH6R24KTSDRI6LTZANCNFSM4LEZHTSQ
.

Gerard Braad | http://gbraad.nl
[ Doing Open Source Matters ]

gbraad on 24 Mar 2020

Linux got added as it was easy and possible

Correct. Following this discussion, I'm leaning towards not providing it for Linux and just leave it to the distro. We could however, provide simple docs for at least our distros (Fedora, RHEL and Centos). WDYT?

zeenix on 24 Mar 2020

I'm leaning towards not providing it for Linux and just leave it to the
distro.

I meant not to provide the whole functionality at all... without a client
there is no need to provide the option.

If we provide the option for podman on Linux, it would be best to provide a
OOTB solution. Convenience of use is key first. Advanced users can always opt
for an alternative by ignoring the provided client.

gbraad on 24 Mar 2020

👍1

I meant not to provide the whole functionality at all... without a client there is no need to provide the option.

Sure but unless we explicitly disable the socket/service in the VM, we'll provide most of the functionality anyway and hence I don't see why we shouldn't continue to provide the crc podman-env subcommand (especially when the code is generic and simple) even if we don't provide a client.

But yeah, I agree that if everything is in place anyway, does not hurt to provide the client as well and have a consistent experience on all platforms.

zeenix on 24 Mar 2020

unless we explicitly disable the socket/service in the VM, we'll provide most of the functionality anyway

right, so the podman-env will report "Unsupported for this platform" as Windows does now. We have to provide a baseline of what the user can expect... if we can't, it is best not to offer this as a full OOTB solution ... (I would NOT like to go this route, but this depends on having a usable client or not... we do not have the bandwidth to test multiple versions).

gbraad on 24 Mar 2020

👍1

I'm having trouble following this conversation for needs to podman ... what can I do to help?

baude on 24 Mar 2020

We need clients for macos, windows an linux on github releases to provide
our needed podman-remote functionality for crc.

On Tue, Mar 24, 2020, 22:39 Brent Baude notifications@github.com wrote:

I'm having trouble following this conversation for needs to podman ...
what can I do to help?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/code-ready/crc/issues/1083#issuecomment-603277261,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAAOZVMFTGTFAIUAT2PNN3RJDAYVANCNFSM4LEZHTSQ
.

gbraad on 24 Mar 2020

@baude they need a staticly linked podman-remote basically for linux.

rhatdan on 25 Mar 2020

👀1

Any updates on this?

gbraad on 30 Mar 2020

@baude they need a staticly linked podman-remote basically for linux.

As said before, Linux isn't the top priority. We just need binaries for both Mac and Windows appearing in one canonical location, first. If Linux binary is also made available, awesome!

zeenix on 1 Apr 2020

Any updates on this?

gbraad on 2 Apr 2020

@fatherlinux What can we do with this issue?

gbraad on 24 Apr 2020

New binaries are available and download code needs to handle tagged release on Github.,

gbraad on 25 May 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

stale[bot] on 31 Aug 2020

@gbraad I believe we have solved these issues now. Is this still an issue for CRC, with what we ship in the release branches of podman?

rhatdan on 8 Sep 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

stale[bot] on 7 Nov 2020

We will create a new issue for Podman 2.0