action #52673
closedos-autoinst: Do not save "lastgood" snapshot on last module unless img is preserved with snapshot (e.g. --no-cleanup)
0%
Description
Motivation¶
it feels a bit wasteful to record snapshots just before successfully finishing a test that prunes the worker pool directory just afterwards:
[2019-06-05T21:52:34.455 CEST] [debug] ||| finished first_boot installation at 2019-06-05 19:52:34 (37 s)
[2019-06-05T21:52:34.456 CEST] [debug] Creating a VM snapshot lastgood
…
[2019-06-05T21:52:35.000 CEST] [debug] Migrating total bytes: 2152538112
[2019-06-05T21:52:35.000 CEST] [debug] Migrating remaining bytes: 2130817024
Suggestion¶
The snapshot is recorded because of the module "first_boot" being a "milestone" module. One idea is that the milestone flag would not make sense on the last module of a test job and should be ignored by os-autoinst for recording a snapshot "lastgood" unless MAKE_TEST_SNAPSHOTS=1
is set which would create a named snapshot but also unless the worker is started with "--no-cleanup" which we can not currently know from within os-autoinst.
Updated by okurz over 5 years ago
- Related to action #52451: test incompletes reproducibly in first_boot of krypton-live-install with "Seems like os-autoinst has produced a result which openQA can not display." added
Updated by okurz over 4 years ago
- Status changed from New to In Progress
- Assignee set to favogt
@favogt you are about to fix that with your PR https://github.com/os-autoinst/os-autoinst/pull/1483
Updated by okurz over 4 years ago
- Status changed from In Progress to Resolved
merged and deployed to production without problems, considered resolved.
Updated by okurz over 4 years ago
- Status changed from Resolved to Feedback
problems found by OSD users: #69432 . The same problem has been present on o3 but unfortunately not been handled.
@favogt I revert the change with https://github.com/os-autoinst/os-autoinst/pull/1490 to handle the problem as soon as possible. Hopefully we can bring back this change and have that problem fixed as well. Would you be happy to give it another shot? #69432 also mentions a good and fast test case that you could use to bisect what part of the change breaks it. I am sure mdoucha can also give helpful support.
Updated by okurz over 4 years ago
- Related to action #69432: test fails with no module details after boot_ltp, broken run-time scheduling? added
Updated by okurz over 4 years ago
updated PR by favogt: https://github.com/os-autoinst/os-autoinst/pull/1492
Updated by okurz over 2 years ago
- Status changed from Feedback to Resolved
cdywan and me just walked over the code and found that the behaviour is actually implemented as we expected so the ticket should be good to be resolved.