QA » openQA Project

Maybe for some more clarity:

The original job layout was:

116539
|-116569
|-116570
\-116571 (terminated incomplete, setup error, cloned to 116768)
         (timimig wise: 116569 & 116570 started ~ 20 minutes after 116539 was completed,
                                 116571 only > 30 minutes later, then failed to perform the setup,
                                 likely for missing assets. Something cleaning out assets too fast?)

Note: The CLONE 11676 already does not have a parent specified anymore (so the auto-cloning of a incomplete job breaks parenting)

Later, 116539 was cloned, new job layout (attempted manual rerun of the test-group)
116831
116832
116833
\-116857

The first two no longer are marked as children, and 'run away' without the asset created by their parent.

the clue from logs, HTH,

[Wed Jan 27 20:38:39 2016] [error] org.freedesktop.DBus.Error.Failed: DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::Pg::st execute failed: ERROR: duplicate key value violates unique constraint "job_dependencies_pkey"
DETAIL: Key (child_job_id, parent_job_id, dependency)=(116830, 116833, 1) already exists. [for Statement "INSERT INTO job_dependencies ( child_job_id, dependency, parent_job_id) VALUES ( ?, ?, ? )" with ParamValues: 1='116830', 2='1', 3='116833'] at /usr/share/openqa/script/../lib/OpenQA/Schema/Result/Jobs.pm line 545

I created test for this scenario and it passes. So the problem must be somewhere else. Looking at the log snipped it complains that the dependency already exists, but checking openqa, there is no such dependency.

Maybe the special thing is that it has three children?

I just cloned install-gnome-image again today (latest TW snapshot)

117874 => 118145 (incomplete? No children!) => 118153

Children misbehaved the same way as the last time: some had no parent and started directly, one waited, and then failed

Yes, I included it in my test, at least I hope. (See https://github.com/aaannz/openQA/commit/53b0783fd4a3b9320298bd92c2533271b81e2c34 ).

Looking at the latest what you posted it's behaving as expected (apart of failing children of the last clone). When you restart parent whose children are in scheduled state, children are not cloned but rerouted to new parent. That was design decision to avoid needles job creating.

See comment https://github.com/os-autoinst/openQA/blob/master/lib/OpenQA/Schema/Result/Jobs.pm#L352

I triggered only one rescheduling of the job: at that time, not single TW job of that image was still running (the snapshot has been released last night)

Everything else was openQA doing

Maybe we didn't understand each other. I'm referring to

117874 => 118145 (incomplete? No children!) => 118153

117874 has 3 children,
118145 was cloned (for whatever reason) before finishing, thus all children had to be in scheduled state, thus it is by design it appears dependencies are broken, no child is displayed in UI
118153 has again 3 children (problem is they failed probably on setup failure, I suspect HDD image is missing or so)

EDIT: Ah, I see what might be misunderstood. By you in the second sentence I was meaning hypothetically. Like 'When one restart parent'. :)

Ah! Sorry, my bad.

the three children on https://openqa.opensuse.org/tests/118153 are actually not the right ones:
if you check them, they all refer to the same test (opensuse-Tumbleweed-DVD-x86_64-Build20160130-sysauth_gnome ) whereas the original parent had three different children.