8:50 p.m.
Dear Personnel,
It seems that the OST is failing due to a storage issue [1]. The failure is
on the test_verify_and_remove_cloned_vm test which is not changed on the
patch [2] .
The engine log prints the error:
2020-12-01 13:07:48,297+01 ERROR
[org.ovirt.engine.core.bll.storage.domain.AttachStorageDomainToPoolCommand]
(default task-1) []
An error occurred while fetching unregistered disks from Storage
Domain id '26d55c27-bf61-4f01-b5a3-d9a6a01c3e8a'2020-12-01
13:07:48,298+01 DEBUG
[org.ovirt.engine.core.bll.storage.domain.AttachStorageDomainToPoolCommand]
(default task-1) [] Skipping format update for domain
'26d55c27-bf61-4f01-b5a3-d9a6a01c3e8a' (type 'ImportExport')
and returns the following error:
2020-12-01 13:17:46,784+01 ERROR
[org.ovirt.engine.api.restapi.resource.AbstractBackendResource]
(default task-2) [] Operation Failed:
[Cannot remove VM. The VM is performing an operation on a Snapshot.
Please wait for the operation to finish, and try again.]
Maybe there is a recent change causing a regression here?
[1]
https://jenkins.ovirt.org/job/ovirt-system-tests_standard-check-patch/14137/
[2]
https://github.com/oVirt/ovirt-system-tests/blob/master/basic-suite-maste...
With Best Regards.
Steven.
9:32 p.m.
On Wed, Dec 2, 2020 at 2:03 PM Nir Soffer <nsoffer(a)redhat.com> wrote:
+Shmuel Melamud <smelamud(a)redhat.com> +Arik Hadas <ahadas(a)redhat.com>
That seems correct. We had https://bugzilla.redhat.com/1177156, as part of
clone VM there is a snapshot created and later removed. It was merged
pretty long ago (Oct 19).
Maybe in the current run you had no luck in the timing but that is just an
indicator this test might be flaky and should have better handling.
12:27 a.m.
The failing test was merged two days ago[1]
A snapshot is created when the VM isn't running as well?
My guess is because snapshot removal runs detached from the parent[2]
(which is correct IMHO), it doesn't have the same correlation_id, so
all_jobs_finished[3] doesn't wait for it. Perhaps snapshot creation/removal
can be skipped if it's a cold clone?
[1] https://gerrit.ovirt.org/c/ovirt-system-tests/+/112039
[2]
https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules...
[3]
https://github.com/oVirt/ovirt-system-tests/blob/master/basic-suite-maste...
On Wed, Dec 2, 2020 at 2:49 PM Liran Rotenberg <lrotenbe(a)redhat.com> wrote:
1:38 a.m.
On Wed, Dec 2, 2020 at 5:27 PM Benny Zlotnik <bzlotnik(a)redhat.com> wrote:
The failing test was merged two days ago[1]
A snapshot is created when the VM isn't running as well?
Yes, the reason is twofold:
1. When you create the snapshot and clone the disks from the snapshot, the
VM can start during the clone operation (no need to wait for the clone
operation to complete before starting the VM)
2. That way the implementation for both running and non-running VM is the
same
We took this approach for export VM to OVA for quite some time
To be honest, I'm not sure that I remember the reason for detaching from
the parent.
I think it was related to compensation but anyway I believe we should
preserve the execution context, and by that probably preserve the
correlation id.
What do you think?
2:27 a.m.
I see
To be honest, I'm not sure that I remember the reason for
detaching from
the parent.
I think it was related to compensation but anyway I believe we should
preserve the execution context, and by that probably preserve the
correlation id.
What do you think?
I'm not sure, AFAIK we usually detach in the endAction
methods when the
child running is async, to prevent NPEs when the parent command is cleared
before the child, but this is usually done if the parent's success does not
depend on the child completing successfully. In my first reply I thought it
was executed in an endAction method, but now that I see it isn't and I'm
not sure if that's the case here
Another thing that may be possible is to set the correlation id in the
parameters, as suggested in Liran's patch[1]
[1] https://gerrit.ovirt.org/c/ovirt-system-tests/+/112469
On Wed, Dec 2, 2020 at 6:38 PM Arik Hadas <ahadas(a)redhat.com> wrote:
1629
days inactive
1629
days old
5 comments
5 participants
participants (5)
-
Arik Hadas -
Benny Zlotnik -
Liran Rotenberg -
Nir Soffer -
Steven Rosenberg