Bug 966854 - Support fully rollback if clone of sandbox fails
Support fully rollback if clone of sandbox fails
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt-sandbox (Show other bugs)
7.0
x86_64 Linux
medium Severity medium
: rc
: ---
Assigned To: Daniel Berrange
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-24 02:42 EDT by Alex Jia
Modified: 2014-06-13 05:28 EDT (History)
7 users (show)

See Also:
Fixed In Version: libvirt-sandbox-0.5.0-4.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-06-13 05:28:48 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Alex Jia 2013-05-24 02:42:18 EDT
Description of problem:

If there is an error part way through cloning a sandbox, some
directories/files may get left partially created, so cloning
also requires a rollback feature like creating a sandbox fails.

Version-Release number of selected component (if applicable):
# rpm -q libvirt-sandbox libvirt
libvirt-sandbox-0.2.0-1.el7.x86_64
libvirt-1.0.5-2.el7.x86_64

How reproducible:
always

Steps to Reproduce:
For libvirt-1.0.5-2.el7.x86_64, the class Container is missing get_unit_path function, and then cloning will be failed.

1. # virt-sandbox-service create -C -u httpd.service http1
2. # virt-sandbox-service start http1
3. # virt-sandbox-service clone http1 clonebox

Actual results:
# virt-sandbox-service clone http1 clonebox
Created sandbox container dir /var/lib/libvirt/filesystems/clonebox
Traceback (most recent call last):
  File "/usr/bin/virt-sandbox-service", line 1171, in <module>
    args.func(args)
  File "/usr/bin/virt-sandbox-service", line 958, in clone
    fd = open(container.get_unit_path())
AttributeError: Container instance has no attribute 'get_unit_path'


Expected results:


Additional info:

# virt-sandbox-service clone http1 clonebox
Created sandbox container dir /var/lib/libvirt/filesystems/clonebox
Traceback (most recent call last):
  File "/usr/bin/virt-sandbox-service", line 1171, in <module>
    args.func(args)
  File "/usr/bin/virt-sandbox-service", line 958, in clone
    fd = open(container.get_unit_path())
AttributeError: Container instance has no attribute 'get_unit_path'

# ls /var/lib/libvirt/filesystems/clonebox
etc  home  root  usr  var

# virt-sandbox-service clone http1 clonebox
/usr/bin/virt-sandbox-service: [Errno 17] File exists: '/var/lib/libvirt/filesystems/clonebox'

In addition, if the last line code of clone() function are failed, we should rollback all of created files/directories such as  /etc/libvirt-sandbox/services/clonebox.sandbox and /etc/systemd/system/clonebox_sandbox.service.
Comment 2 Daniel Berrange 2013-10-02 13:01:47 EDT
commit 294573e200ae6c4005ce298a7d3d008ef6da6cb5
Author: Daniel P. Berrange <berrange@redhat.com>
Date:   Wed Oct 2 18:00:32 2013 +0100

    Rollback state if cloning container fails part way
    
    Wrap the entire container clone process in an exception handling
    block which deletes the (partially created) new container on
    error. Also sanity check if the target container exists before
    attempting to clone.
Comment 4 Alex Jia 2013-10-09 06:15:47 EDT
I haven't found a good test scenario for cloning container fails, so I directly hacking clone() in /usr/bin/virt-sandbox-service and change get_unit_path to get_unit_path_noexist in line 946 from /usr/bin/virt-sandbox-service on sandbox-0.5.0-5.el7.x86_64, and then the /etc/systemd/system/myclonebox_sandbox.service and /etc/libvirt-sandbox/services/myclonebox/config/sandbox.cfg don't exist, it's a expected result, but the directory /var/lib/libvirt/filesystems/myclonebox still exists, moreover, I will get /var/lib/libvirt/filesystems/myclonebox already exists error when I clone it again, the following is details:

# rpm -q libvirt-sandbox libvirt
libvirt-sandbox-0.5.0-5.el7.x86_64
libvirt-1.1.1-8.el7.x86_64


# virt-sandbox-service create -C -u httpd.service myhttp
Created sandbox container dir /var/lib/libvirt/filesystems/myhttp
Created unit file /etc/systemd/system/myhttp_sandbox.service
Created sandbox config /etc/libvirt-sandbox/services/myhttp/config/sandbox.cfg

# virsh -c lxc:/// list --inactive
 Id    Name                           State
----------------------------------------------------
 -     myhttp                         shut off

# virsh -c lxc:/// start myhttp
Domain myhttp started

# virsh -c lxc:/// list
 Id    Name                           State
----------------------------------------------------
 18136 myhttp                         running

# sed -n 946p /usr/bin/virt-sandbox-service
            fd = open(container.get_unit_path_noexist())

# virt-sandbox-service clone myhttp myhttp_clone
Created sandbox container dir /var/lib/libvirt/filesystems/myhttp_clone
Traceback (most recent call last):
  File "/usr/bin/virt-sandbox-service", line 1217, in <module>
    args.func(args)
  File "/usr/bin/virt-sandbox-service", line 946, in clone
    fd = open(container.get_unit_path_noexist())
AttributeError: SystemdContainer instance has no attribute 'get_unit_path_noexist'

# ls /etc/systemd/system/myhttp_clone_sandbox.service /etc/libvirt-sandbox/services/myhttp_clone/config/sandbox.cfg
ls: cannot access /etc/systemd/system/myhttp_clone_sandbox.service: No such file or directory
ls: cannot access /etc/libvirt-sandbox/services/myhttp_clone/config/sandbox.cfg: No such file or directory

Notes, it's a expected result.

# ls /var/lib/libvirt/filesystems/myhttp_clone
etc  home  root  usr  var

# virt-sandbox-service clone myhttp myhttp_clone
/usr/bin/virt-sandbox-service: /var/lib/libvirt/filesystems/myhttp_clone already exists
Comment 5 Alex Jia 2013-10-31 04:49:15 EDT
Daniel, any suggestion about this? thanks.
Comment 6 weizhang 2013-12-10 00:57:36 EST
Hi Daniel, could you please help to check the issue in comment 4? Thanks
Comment 7 Daniel Berrange 2014-01-29 05:56:10 EST
I don't think that changing the code to throw a python error is a reasonable test of this. It is impossible to rollback correctly in every possible scenario which involves a coding error. The goal is only to rollback in scenarios which involve environmental errors. eg say if there was a failure to copy a file due to disk full, or some other OS error then we would rollback.
Comment 8 Alex Jia 2014-01-29 21:52:15 EST
(In reply to Daniel Berrange from comment #7)
> I don't think that changing the code to throw a python error is a reasonable
> test of this. It is impossible to rollback correctly in every possible
> scenario which involves a coding error. The goal is only to rollback in
> scenarios which involve environmental errors. eg say if there was a failure
> to copy a file due to disk full, or some other OS error then we would
> rollback.

Well, no real test scenario can hit this, so move it to VERIFIED status.

# rpm -q libvirt-sandbox libvirt kernel
libvirt-sandbox-0.5.0-8.el7.x86_64
libvirt-1.1.1-20.el7.x86_64
kernel-3.10.0-67.el7.x86_64
Comment 10 Ludek Smid 2014-06-13 05:28:48 EDT
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.

Note You need to log in before you can comment on or make changes to this bug.