#107 provision: unable to copy a directory in the VM
Closed: Fixed 3 years ago by frantisekz. Opened 3 years ago by ttomecek.

Hi, I'm opening this issue while using testcloud via tmt. My plan references a file which is in a subdirectory and it seems testcloud is having problems with copying the tree structure in the VM:

$ tmt run plan --name linters
/var/tmp/tmt/run-001

/plans/linters
    discover
        how: shell
        directory: /home/tt/g/user-cont/ogr
        summary: 1 test selected
    provision
        how: virtual
        image: fedora
        user: root
        memory: 2048 MB
        disk: 10 GB
        progress: downloading...
    finish
        summary: 0 tasks completed
Traceback (most recent call last):
  File "/usr/bin/tmt", line 8, in <module>
    tmt.cli.main()
  File "/usr/lib/python3.9/site-packages/click/core.py", line 829, in __call__
    return self.main(*args, **kwargs)
  File "/usr/lib/python3.9/site-packages/click/core.py", line 782, in main
    rv = self.invoke(ctx)
  File "/usr/lib/python3.9/site-packages/click/core.py", line 1259, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/lib/python3.9/site-packages/click/core.py", line 1290, in invoke
    return _process_result(rv)
  File "/usr/lib/python3.9/site-packages/click/core.py", line 1224, in _process_result
    value = ctx.invoke(self.result_callback, value, **ctx.params)
  File "/usr/lib/python3.9/site-packages/click/core.py", line 610, in invoke
    return callback(*args, **kwargs)
  File "/usr/lib/python3.9/site-packages/click/decorators.py", line 21, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "/usr/lib/python3.9/site-packages/tmt/cli.py", line 300, in finito
    click_context.obj.run.go()
  File "/usr/lib/python3.9/site-packages/tmt/base.py", line 1404, in go
    plan.go()
  File "/usr/lib/python3.9/site-packages/tmt/base.py", line 765, in go
    step.go()
  File "/usr/lib/python3.9/site-packages/tmt/steps/provision/__init__.py", line 95, in go
    plugin.go()
  File "/usr/lib/python3.9/site-packages/tmt/steps/provision/testcloud.py", line 235, in go
    self._guest.start()
  File "/usr/lib/python3.9/site-packages/tmt/steps/provision/testcloud.py", line 420, in start
    self.image.prepare()
  File "/usr/lib/python3.9/site-packages/testcloud/image.py", line 208, in prepare
    self._handle_file_url(self.remote_path, self.local_path, copy=copy)
  File "/usr/lib/python3.9/site-packages/testcloud/image.py", line 165, in _handle_file_url
    shutil.copy(source_path, dest_path)
  File "/usr/lib64/python3.9/shutil.py", line 418, in copy
    copyfile(src, dst, follow_symlinks=follow_symlinks)
  File "/usr/lib64/python3.9/shutil.py", line 264, in copyfile
    with open(src, 'rb') as fsrc, open(dst, 'wb') as fdst:
IsADirectoryError: [Errno 21] Is a directory: 'fedora'

the plan:

summary:
  Run linters on source code and packaging files
prepare:
  - name: packages
    how: install
    package:
    - rpmlint
execute:
  script:
  - rpmlint fedora/python-ogr.spec

Metadata Update from @frantisekz:
- Issue assigned to frantisekz

3 years ago

@psss this seems like an issue tmt side?

Testcloud image object with this scenario looks like this:

$ tmt run plan --name linters
/var/tmp/tmt/run-025

/plans/linters
    discover
        how: shell
        directory: /home/fanys/packages/python-ogr
        summary: 1 test selected
    provision
        how: virtual
        image: fedora
        user: root
        memory: 2048 MB
        disk: 10 GB
        progress: downloading...
> /usr/lib/python3.9/site-packages/testcloud/image.py(181)_handle_file_url()
    180         import ipdb; ipdb.set_trace()
--> 181         if not os.path.exists(dest_path):
    182             if source_path.endswith('.xz'):

ipdb> self                                                                                                                                                                                                     
<testcloud.image.Image object at 0x7fef6bf494c0>
ipdb> self.local_path                                                                                                                                                                                          
'/var/tmp/tmt/testcloud/images/fedora'
ipdb> self.remote_path                                                                                                                                                                                         
'fedora'
ipdb> self.uri                                                                                                                                                                                                 
'file://fedora'
ipdb>

where it should have Image.remote_path and Image.uri set to image uris imo. What do you think? It seems this got passed to us from tmt in this way.

Yeah, this is a bug in tmt caused by guessing images from short image names:

The ogr repo contains a fedora directory which confused the image guessing. A quick workaround is to explicitly provide an image name, for example:

tmt run -a provision -h virtual -i f34

Should be fixed, closing (please, re-open in case its still an issue somehow.)

Metadata Update from @frantisekz:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

3 years ago

Log in to comment on this ticket.

Metadata