Skip to content
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

Podman v2 no longer allows clearing of entrypoint on the command line #6935

Closed
pzl opened this issue Jul 10, 2020 · 10 comments
Closed

Podman v2 no longer allows clearing of entrypoint on the command line #6935

pzl opened this issue Jul 10, 2020 · 10 comments
Labels
kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.

Comments

@pzl
Copy link

pzl commented Jul 10, 2020

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

Previously, it was possible to override and erase the entrypoint of an image on the CLI. After the switch to cobra flag parsing, it seems that is no longer the case

Steps to reproduce the issue:

  1. podman run --rm -it --entrypoint= alpine/git sh

Describe the results you received:

git: 'sh' is not a git command. See 'git --help'.

The most similar commands are
	show
	push

i.e. git sh was run

Describe the results you expected:

an sh prompt

Additional information you deem important (e.g. issue happens only occasionally):

the alpine/git image is small enough to reason with: source. It simply sets git as the entrypoint. I used to be able to erase the entrypoint entirely, and have sh be the command. Sure, I can work around this by setting sh as the entrypoint here, but for the general case, entrypoints cannot be erased anymore. Just overridden to a new value.

Here is the previous introduction of the feature: #585

Output of podman version:

Version:      2.0.1
API Version:  1
Go Version:   go1.14.4
Git Commit:   a11c4ead10177a66ef2810a0a92ea8ce2299da07
Built:        Sat Jun 27 16:04:26 2020
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.15.0
  cgroupVersion: v2
  conmon:
    package: Unknown
    path: /usr/bin/conmon
    version: 'conmon version 2.0.18, commit: 7b3e303be8f1aea7e0d4a784c8e64a75c14756a4'
  cpus: 32
  distribution:
    distribution: arch
    version: unknown
  eventLogger: file
  hostname: architower
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 5.7.7-arch1-1
  linkmode: dynamic
  memFree: 22871597056
  memTotal: 33644826624
  ociRuntime:
    name: crun
    package: Unknown
    path: /usr/bin/crun
    version: |-
      crun version 0.14
      commit: ebc56fc9bcce4b3208bb0079636c80545122bf58
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  os: linux
  remoteSocket:
    path: /run/user/1000/podman/podman.sock
  rootless: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: Unknown
    version: |-
      slirp4netns version 1.1.2
      commit: 0806e04b1f786070cc1695d7f9b6abd43862bb5a
      libslirp: 4.3.0
      SLIRP_CONFIG_VERSION_MAX: 3
  swapFree: 0
  swapTotal: 0
  uptime: 4h 38m 8.01s (Approximately 0.17 days)
registries:
  search:
  - docker.io
  - registry.fedoraproject.org
  - quay.io
  - registry.access.redhat.com
  - registry.centos.org
store:
  configFile: /home/dan/.config/containers/storage.conf
  containerStore:
    number: 1
    paused: 0
    running: 1
    stopped: 0
  graphDriverName: vfs
  graphOptions: {}
  graphRoot: /home/dan/.config/data/containers/storage
  graphStatus: {}
  imageStore:
    number: 8
  runRoot: /run/user/1000/containers
  volumePath: /home/dan/.config/data/containers/storage/volumes
version:
  APIVersion: 1
  Built: 1593288266
  BuiltTime: Sat Jun 27 16:04:26 2020
  GitCommit: a11c4ead10177a66ef2810a0a92ea8ce2299da07
  GoVersion: go1.14.4
  OsArch: linux/amd64
  Version: 2.0.1

Package info (e.g. output of rpm -q podman or apt list podman):

Name            : podman
Version         : 2.0.1-1
Description     : Tool and library for running OCI-based containers in pods
Architecture    : x86_64
URL             : https://github.com/containers/libpod
Licenses        : Apache
Groups          : None
Provides        : None
Depends On      : cni-plugins  conmon  device-mapper  iptables  libseccomp  runc  slirp4netns  libsystemd  fuse-overlayfs  skopeo
Optional Deps   : podman-docker: for Docker-compatible CLI
                  btrfs-progs: support btrfs backend devices [installed]
                  catatonit: --init flag support
                  crun: support for unified cgroupsv2 [installed]
Required By     : None
Optional For    : None
Conflicts With  : None
Replaces        : None
Installed Size  : 89.15 MiB
Packager        : Morten Linderud <foxboron@archlinux.org>
Build Date      : Sat 27 Jun 2020 04:04:26 PM EDT
Install Date    : Sat 27 Jun 2020 09:42:52 PM EDT
Install Reason  : Explicitly installed
Install Script  : No
Validated By    : Signature
@openshift-ci-robot openshift-ci-robot added the kind/bug Categorizes issue or PR as related to a bug. label Jul 10, 2020
@skorhone
Copy link

skorhone commented Jul 10, 2020

It could be that I don't fully understand how pflags works... or it could be that parsing logic is flawed. All strings seem to default as empty when parsing. I don't see any way, how you would differentiate between an empty string set by user and a default value of empty.

Code that I looked at can be found here: podman/cmd/podman/common/create.go

For some reason entrypoint and few other bits are not parsed the same way that other variables using.

Considering that pflags provides neat interface for handling differences between set, empty and unset values, it might make sense to refactor code to make most of it.

My suggestion would be to have type ContainerCLIOpts store pflags as they are. Then provide named accessor functions to access values, so that you don't get magic variables all over the codebase. Accessor such as entrypoint could return ok, if there is actually a value defined

Should be trivial to fix and I could do it myself, if I wasn't on vacation 🙂

@skorhone
Copy link

Creating an interface for reading parameters would allow sharing code between API and cli. Interface could be used as one of input parameters to function that forms container spec: options + image + config -> spec -> container

@Luap99
Copy link
Member

Luap99 commented Jul 10, 2020

It could be that I don't fully understand how pflags works... or it could be that parsing logic is flawed. All strings seem to default as empty when parsing. I don't see any way, how you would differentiate between an empty string set by user and a default value of empty.

You can use something like: cmd.Flag("entrypoint").Changed. This will only be true if the flag is set on the command line.

@skorhone
Copy link

You could, but it would be a dirty hack. As is, code is really hard to follow. But as a quick fix, it should work.

Move to ContainerCLIOpts seems like a step towards having common structure and away from magic variables ("entrypoint" = magic var). It just needs another iteration with some love and care. And it desperately needs unit tests

@vincent-olivert-riera
Copy link

vincent-olivert-riera commented Jul 11, 2020

I'm also having this same issue. Before I was able to clear the entry point with --entrypoint="", but now it does not work any more.

$ podman version
Version:      2.0.2
API Version:  1
Go Version:   go1.14.3
Built:        Thu Jan  1 01:00:00 1970
OS/Arch:      linux/amd64

That's the current version provided by Fedora 32, so this must be affecting many people.

@rhatdan
Copy link
Member

rhatdan commented Jul 11, 2020

As a work around this should work.

podman run --rm -it --entrypoint=sh alpine/git

@vincent-olivert-riera
Copy link

vincent-olivert-riera commented Jul 11, 2020

As a work around this should work.

podman run --rm -it --entrypoint=sh alpine/git

That's a workaround valid only for that particular case, because you want to run the sh command in that container.

I think that example was used just as a simple scenario to demonstrate the problem.

@rhatdan
Copy link
Member

rhatdan commented Jul 13, 2020

Yes, I was only suggesting it for your case. Hopefully My PR will get merged soon, and then we can back port it into podman-2.0.3

@vincent-olivert-riera
Copy link

@rhatdan that would be great :-) Thanks for taking care of this.

@vincent-olivert-riera
Copy link

@pzl , this has been fixed: #6939

@rhatdan rhatdan closed this as completed Jul 15, 2020
@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 23, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 23, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.
Projects
None yet
Development

No branches or pull requests

6 participants