Project

General

Profile

Actions

action #15448

closed

Hole in ths staging process: issues can be missed

Added by dimstar over 7 years ago. Updated almost 7 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
2016-12-12
Due date:
% Done:

100%

Estimated time:

Description

Whenever a new kernel comes in to staging, we have a shortcoming in our staging process:

  • A new kernel is added to :LETTER
  • The kernel, and related packages build
  • openQA happens

The main problem we see (again) is that all the rest of the staging is not being rebuilt and MIGHT have a problem with the new kernel RUNNING (e.g. just see with strace: it fails to pass the test suite with 4.8.13 being the running kernel - but this was not spotted during the staging process)

We need a way to guarantee that:

  • kernel-obs-build is amongst the first packages to be built
  • A full rebuilt of the project is done based on this new kernel

(this makes staging a kernel slower, but it's not the first time we run into this issue and it keeps on popping up)

Actions #1

Updated by dimstar over 7 years ago

The kernel is actually only one sample of packages that we can miss... (for strace it was red-herring and a co-incidence: 'grep' was the cause)

So this issue expands to everything in VMinstall and preinstall it seems

Actions #2

Updated by dimstar over 7 years ago

  • Subject changed from Kernel staging issue to Hole in ths staging process: issues can be missed
Actions #3

Updated by okurz over 7 years ago

does the new kernel testing group on openQA help maybe?: https://openqa.opensuse.org/group_overview/32

I don't quite understand what you propose. It is pretty obvious that staging can (by definition) only run a subset of tests so there will be always something missed, isn't it?

Actions #4

Updated by adrian@suse.de over 7 years ago

On Freitag, 16. Dezember 2016, 07:35:55 CET wrote redmine@opensuse.org:

[openSUSE Tracker]
Issue #15448 has been updated by okurz.

does the new kernel testing group on openQA help maybe?: https://openqa.opensuse.org/group_overview/32

I don't quite understand what you propose. It is pretty obvious that staging can (by definition) only run a subset of tests so there will be always something missed, isn't it?


action #15448: Hole in ths staging process: issues can be missed
https://progress.opensuse.org/issues/15448#change-34360

  • Author: dimstar
  • Status: New
  • Priority: Normal
  • Assignee: mlin7442
  • Category:

* Target version:

Whenever a new kernel comes in to staging, we have a shortcoming in our staging process:

  • A new kernel is added to :LETTER
  • The kernel, and related packages build
  • openQA happens

The main problem we see (again) is that all the rest of the staging is not being rebuilt and MIGHT have a problem with the new kernel RUNNING (e.g. just see with strace: it fails to pass the test suite with 4.8.13 being the running kernel - but this was not spotted during the staging process)

We need a way to guarantee that:

  • kernel-obs-build is amongst the first packages to be built

Just declare kernel-obs-build as not supported again.

However, you should only do so in Staging projects using

Suppport: !kernel-obs-build

there

  • A full rebuilt of the project is done based on this new kernel

(this makes staging a kernel slower, but it's not the first time we run into this issue and it keeps on popping up)

--

Adrian Schroeter
email: adrian@suse.de

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)

Maxfeldstraße 5

90409 Nürnberg
Germany

Actions #5

Updated by adrian@suse.de over 7 years ago

On Freitag, 16. Dezember 2016, 08:22:22 CET wrote redmine@opensuse.org:

[openSUSE Tracker]
Issue #15448 has been updated by adrian@suse.de.

On Freitag, 16. Dezember 2016, 07:35:55 CET wrote redmine@opensuse.org:

[openSUSE Tracker]
Issue #15448 has been updated by okurz.

does the new kernel testing group on openQA help maybe?: https://openqa.opensuse.org/group_overview/32

I don't quite understand what you propose. It is pretty obvious that staging can (by definition) only run a subset of tests so there will be always something missed, isn't it?


action #15448: Hole in ths staging process: issues can be missed
https://progress.opensuse.org/issues/15448#change-34360

  • Author: dimstar
  • Status: New
  • Priority: Normal
  • Assignee: mlin7442
  • Category:

* Target version:

Whenever a new kernel comes in to staging, we have a shortcoming in our staging process:

  • A new kernel is added to :LETTER
  • The kernel, and related packages build
  • openQA happens

The main problem we see (again) is that all the rest of the staging is not being rebuilt and MIGHT have a problem with the new kernel RUNNING (e.g. just see with strace: it fails to pass the test suite with 4.8.13 being the running kernel - but this was not spotted during the staging process)

We need a way to guarantee that:

  • kernel-obs-build is amongst the first packages to be built

Just declare kernel-obs-build as not supported again.

this can be misread;) I mean, just remove the "Support" flag
for it. That way the OBS will have it again in build meta data
and will trigger all packages on a change.

However, you should only do so in Staging projects using

Suppport: !kernel-obs-build

there

  • A full rebuilt of the project is done based on this new kernel

(this makes staging a kernel slower, but it's not the first time we run into this issue and it keeps on popping up)

--

Adrian Schroeter
email: adrian@suse.de

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)

Maxfeldstraße 5

90409 Nürnberg
Germany

Actions #6

Updated by dimstar over 7 years ago

The kernel is only one example... as I wrote already. Don't get hung up on this. We need a generic approach for the problems

As said: in the previous case for example we missed 'grep' having a regression; as nothing buildrequires grep (and still assumes it's there) - it's a great candidate. Rebuild=direct won't ever catch it (it's part of preinstall)

Actions #7

Updated by mlin7442 about 7 years ago

  • Status changed from New to In Progress
Actions #8

Updated by lnussel about 7 years ago

So we switch to transitive rebuild mode?

Actions #9

Updated by mlin7442 about 7 years ago

lnussel wrote:

So we switch to transitive rebuild mode?

well, that would still not good enough for Preinstall and VMinstall, need to check whether the staged request lists in Preinstall or Vminstall, if so waiting new build done and rebuild the others.

Actions #10

Updated by mlin7442 almost 7 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 0 to 100

Handled by suppkg_rebuild already.

Actions

Also available in: Atom PDF