action #20310
open[qe-core][qem] have a reference system patch and reboot in a specific time
0%
Description
We have several test that patch_and_reboot, but we have none where we expect
the system in a specific time to be alive again. Meaning LAMP stack back on.
As the recent openssl regression showed, this is crucial not to miss - the default
timeouts are just too forgiving (and do not check if postgresql/mysql/apache/openssh
start in time).
Updated by pcervinka about 5 years ago
- Assignee set to osukup
@osukup, is it there anything we can do about it?
Updated by tjyrinki_suse over 3 years ago
- Subject changed from [qam] have a reference system patch and reboot in a specific time to [qe-core][qam] have a reference system patch and reboot in a specific time
Updated by tjyrinki_suse over 3 years ago
- Subject changed from [qe-core][qam] have a reference system patch and reboot in a specific time to [qe-core][qem] have a reference system patch and reboot in a specific time
Updated by okurz over 2 years ago
This ticket was set to "Normal" priority but was not updated within the SLO period for "Normal" tickets (365 days) as described on https://progress.opensuse.org/projects/openqatests/wiki/Wiki#SLOs-service-level-objectives. Please consider picking up this ticket within the next 365 days or just set the ticket to the next lower priority of "Low" (no SLO related time period).
Updated by slo-gin over 1 year ago
This ticket was set to Normal priority but was not updated within the SLO period. Please consider picking up this ticket or just set the ticket to the next lower priority.
Updated by szarate about 1 year ago
- Tags set to qe-core-april-sprint
The first thing here:
- How long can we accept to wait, and what would be the delta between acceptable and unacceptable?.
- Define what "in time" means here:
As the recent openssl regression showed, this is crucial not to miss - the default
timeouts are just too forgiving (and do not check if postgresql/mysql/apache/openssh
start in time).
Would be great to know which was the regression that made Coolo create this ticket
Updated by okurz about 1 year ago
szarate wrote:
The first thing here:
- How long can we accept to wait, and what would be the delta between acceptable and unacceptable?.
- Define what "in time" means here:
Well, that's what QA engineers "the advocates of customers" should decide, i.e. you. I suggest as baseline something as simple as "the current usual boot time + 20% margin". But to allow for statistical variations reboot 5 times and take the median value
Updated by slo-gin about 1 month ago
This ticket was set to Normal priority but was not updated within the SLO period. Please consider picking up this ticket or just set the ticket to the next lower priority.