Project

General

Profile

Actions

action #20310

open

[qe-core][qem] have a reference system patch and reboot in a specific time

Added by coolo almost 7 years ago. Updated about 2 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
New test
Target version:
-
Start date:
2017-07-07
Due date:
% Done:

0%

Estimated time:
Difficulty:

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).

Actions #1

Updated by pcervinka about 5 years ago

  • Assignee set to osukup

@osukup, is it there anything we can do about it?

Actions #2

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
Actions #3

Updated by osukup over 3 years ago

  • Assignee deleted (osukup)
Actions #4

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
Actions #5

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).

Actions #6

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.

Actions #7

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

Actions #8

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

Actions #9

Updated by slo-gin about 2 months 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.

Actions

Also available in: Atom PDF