Podman: APIv2 container restore query parameter name is not working

[ypu]

Is this a BUG REPORT or FEATURE REQUEST?

/kind bug

Description
APIv2 container restore query parameter name is not working. When try to import restore from a file with name, curl command always restore to the origin container.

Also there is a query parameter "leaveRunning" exist in restore, maybe we should remove it from restore.

Steps to reproduce the issue:

1. Start a podman service

# podman system service --timeout 0 tcp:127.0.0.1:80

1. Create a restore file

# podman run -d --name test busybox sleep 999
# podman container checkpoint -e checkpoint.tar.gz test

1. Restore from the file with curl

# curl -s -v -X POST -H "Content-Type: application/tar" --data-binary "@checkpoint.tar.gz"  "http://localhost:80/v1.40/libpod/containers/test/restore?import=true&name=testname"
*   Trying ::1:80...
* connect to ::1 port 80 failed: Connection refused
*   Trying 127.0.0.1:80...
* Connected to localhost (127.0.0.1) port 80 (#0)
> POST /v1.40/libpod/containers/test/restore?import=true&name=testname HTTP/1.1
> Host: localhost
> User-Agent: curl/7.69.1
> Accept: */*
> Content-Type: application/tar
> Content-Length: 19627
> 
* upload completely sent off: 19627 out of 19627 bytes
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Type: application/json
< Date: Mon, 08 Jun 2020 14:08:47 GMT
< Content-Length: 85
< 
{"Err":null,"Id":"d48d3d1dac1f8a267e54c028b46d6c029cfdae8b9e57ba253c8abe14b6fc1933"}
* Connection #0 to host localhost left intact

1. Double check with podman ps

# podman ps -a
CONTAINER ID  IMAGE                             COMMAND    CREATED         STATUS             PORTS   NAMES
d48d3d1dac1f  docker.io/library/busybox:latest  sleep 999  35 seconds ago  Up 34 seconds ago          test

Describe the results you received:
The command return the origin ID of the container instead create a new one.

Describe the results you expected:
A new container named testname should be create. And there are two containers running in step 4.

Additional information you deem important (e.g. issue happens only occasionally):
Using upstream master (HEAD: 1fcb678) with a fedora 32 OS.

Output of podman info --debug:

# podman info --debug
host:
  arch: amd64
  buildahVersion: 1.15.0-dev
  cgroupVersion: v1
  conmon:
    package: conmon-2.0.15-1.fc32.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.15, commit: 33da5ef83bf2abc7965fc37980a49d02fdb71826'
  cpus: 4
  distribution:
    distribution: fedora
    version: "32"
  eventLogger: file
  hostname: bootp-73-3-208.eng.pek2.redhat.com
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 5.6.13-300.fc32.x86_64
  linkmode: dynamic
  memFree: 5278375936
  memTotal: 8340013056
  ociRuntime:
    name: runc
    package: runc-1.0.0-144.dev.gite6555cc.fc32.x86_64
    path: /usr/bin/runc
    version: |-
      runc version 1.0.0-rc10+dev
      commit: fbdbaf85ecbc0e077f336c03062710435607dbf1
      spec: 1.0.1-dev
  os: linux
  remoteSocket:
    path: /run/podman/podman.sock
  rootless: false
  slirp4netns:
    executable: ""
    package: ""
    version: ""
  swapFree: 4294963200
  swapTotal: 4294963200
  uptime: 153h 44m 26.56s (Approximately 6.38 days)
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - registry.centos.org
  - docker.io
store:
  configFile: /etc/containers/storage.conf
  containerStore:
    number: 5
    paused: 0
    running: 4
    stopped: 1
  graphDriverName: overlay
  graphOptions:
    overlay.mountopt: nodev,metacopy=on
  graphRoot: /var/lib/containers/storage
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "true"
  imageStore:
    number: 11
  runRoot: /var/run/containers/storage
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 1
  Built: 1591605022
  BuiltTime: Mon Jun  8 16:30:22 2020
  GitCommit: 1fcb6788a5d7471a7ca6215a40e36e21812a0f6e-dirty
  GoVersion: go1.14.2
  OsArch: linux/amd64
  Version: 2.0.0-dev

[github-actions[bot]]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@baude PTAL

[vrothberg]

I think the restore endpoint needs a general rework, which I want to discuss before further touching the code.

"/libpod/containers/{name}/restore"

As shown above, the endpoint expects a container to exist (i.e., name parameter in path). However, a container mustn't exist in the storage when importing an archive. The local client even rejects additional arguments when using -i.

I suggest to change the endpoint to "/libpod/containers/restore" to account for the fact that a container mustn't exist and then also fix the issues with it.

@baude @jwhonce @mheon @rhatdan PTAL

[mheon]

Should we consider splitting this into two endpoints - one that makes containers, one that restores existing containers? I don't really like APIs that do vastly different things based on parameters.

[rhatdan]

Makes sense to me.

[rhatdan]

@mheon @vrothberg @jwhonce @baude What is going on with this issue? Anything?