Bug: stacker convert replaces Docker COPY with the Stacker import directive - but doesn't take into account differences in behavior

[andaaron]

stacker version

stacker version stacker v1.0.0-rc4-8e267fc liblxc 727adc05220e9b8b594c5bc2124bef5b2e0abe7a

Describe the bug

Stacker convert takes the parameters of docker COPY, and uses them for import source and destination.
The issue is they are not equivalent.

Let's say we have

folder1
├── file1
└── file2

COPY folder1 / copies the content under / at destination: /file1 and /file2. Same result for COPY folder1/ /.
If the user wants to have the source folder at destination, he needs to explicitly mention it COPY folder1 /folder1/.

Stacker does not behave the same:

  import:
  - dest: /
    path: folder1/

In the new image stacker build would create the /folder1/file1 and /folder1/file2.
To my knowledge at the moment there is no way to avoid creating /folder1 and simply put /file1 and /file2 under /.

To reproduce

Create the dockerfile:

FROM ubuntu:latest
COPY folder1/ /
CMD ["ls", "/"]

Build the dockerfle and run it. You will get something like:

bin
boot
dev
etc
file1
file2
home
lib
lib32
lib64
libx32
media
mnt
opt
proc
root
run
sbin
srv
sys
tmp
usr
var

Run stacker convert
Update stacker.yaml to add the run directive (but do not touch the import).
You should obtain something like:

${{IMAGE}}:
  build_env:
    arch: x86_64
  cmd:
  - ls
  - /
  from:
    type: docker
    url: docker://ubuntu:latest
  import:
  - dest: /
    path: folder1/
  run: ls /

Run stacker build. You should see:

stacker build --substitute IMAGE=asd --no-cache
preparing image asd...
loading docker://ubuntu:latest
Copying blob 2ab09b027e7f done
Copying config 08d22c0ceb done
Writing manifest to image destination
Storing signatures
overlay dest / is a symlink, patching to
+ ls /
bin
boot
dev
etc
folder1
home
lib
lib32
lib64
libx32
media
mnt
opt
proc
root
run
sbin
srv
stacker
sys
tmp
usr
var
filesystem asd built successfully

As you can see in the case of docker, the files file1 and file2 are under /, while in case of stacker folder1 is under root (whick contains the 2 files).

Expected behavior

The expected behavior is for stacker convert to produce a stacker.yaml which has the same behavior as the original Dockerfile.
We also need to add a way in stacker to avoid crating the extra folder (ideally without breaking existing stacker yamls).

Screenshots

No response

Additional context

No response