Project

General

Profile

Actions

action #63199

closed

ObsRsync obsoletes rather than deprioritizes older builds

Added by okurz about 4 years ago. Updated about 4 years ago.

Status:
Resolved
Priority:
High
Assignee:
-
Category:
Regressions/Crashes
Target version:
Start date:
2020-02-06
Due date:
% Done:

100%

Estimated time:

Description

Observation

See
https://chat.suse.de/channel/testing?msg=TgasFXr3CnzDf8FLa

it seems that ObsRsync misses the feature to deprioritize older builds rather than obsolete as we did with https://gitlab.suse.de/openqa/scripts/blob/master/openqa-iso-sync-sles#L26

Actions #1

Updated by okurz about 4 years ago

  • Description updated (diff)
Actions #2

Updated by okurz about 4 years ago

  • Priority changed from Normal to High
  • Target version set to Current Sprint

sweiberg confirmed that the current behaviour of obsrsync is that still running jobs in older builds are obsoleted when they should not be obsoleted. This means that the RMs need to more carefully select a time when they manually release a new build to testing in openQA to not abort jobs in older builds prematurely.

Actions #3

Updated by coolo about 4 years ago

If I get the code right, we should see _DEPRIORITIZEBUILD used - the last time this was the case was 38.1 for sp2 5 months ago. So I don't think ObsRsync switch is the reason

Actions #4

Updated by andriinikitin about 4 years ago

Yeah I did try to explain in private already that rsync.pl didn't use mentioned deprio options, so all projects were run with equivalent _OBSOLETE=1
But the ObsRsync might have such option like 'obsolete=0' per project configured in xml. I plan to add this feature - and the only missing part is the list of projects which should use it. Or should all IBS projects have _OBSOLETE=1 removed?

Actions #5

Updated by coolo about 4 years ago

No, staging projects need obsolete for sure. It's only sync-sles who set it afaik

Actions #6

Updated by okurz about 4 years ago

Yes, likely that only used by SLE by default as visible in https://gitlab.suse.de/openqa/scripts/blob/master/openqa-iso-sync-sles#L26 , the trigger wrapper script used. I am not aware since when obsrsync is used for 15sp2. Maybe it was only effective for 12sp5, maybe broken with change from _NOOBSOLETE to _OBSOLETE. Just saying that we had this feature and we ran into a situation where we can benefit from it again.

At best the configuration files can take flags that are passed through to openQA without ObsRsync needing to know the specific flags.

Actions #7

Updated by andriinikitin about 4 years ago

Thinking about possible scenarios - it looks every project except stagings needs _OBSOLETE=1 _ONLY_OBSOLETE_SAME_BUILD=1 and the stagings need just _OBSOLETE=1. (both o3 and osd).

I am not sure in which scenarios _DEPRIORITIZEBUILD=1 can be useful, because it will likely still cancel scheduled tests for big projects. And also I don't think it is useful when the same build is re-scheduled for some reasons.

Could you confirm that my understanding is correct or do these options work differently?

Actions #8

Updated by okurz about 4 years ago

andriinikitin wrote:

Thinking about possible scenarios - it looks every project except stagings needs _OBSOLETE=1 _ONLY_OBSOLETE_SAME_BUILD=1 and the stagings need just _OBSOLETE=1. (both o3 and osd).

Not sure how you come to that conclusion. For a start I suggest to just use what we had in before as baseline.

I am not sure in which scenarios _DEPRIORITIZEBUILD=1 can be useful, because it will likely still cancel scheduled tests for big projects

I don't know what you mean with "it will likely still cancel scheduled tests for big projects". The idea of the deprioritization is described in http://open.qa/docs/#_spawning_multiple_jobs_based_on_templates_isos_post with "Setting this switch to '1' will deprioritize the unfinished jobs of old builds, and it will obsolete the jobs once the configurable limit of priority is reached." and the limit can also be configured.

And also I don't think it is useful when the same build is re-scheduled for some reasons.

Could you confirm that my understanding is correct or do these options work differently?

AFAIR _ONLY_OBSOLETE_SAME_BUILD was never used by openSUSE/SLE , the corresponding support to openQA was added by "Adam Williamson awilliam@redhat.com" in 16af146ab.

Why not pass through parameters to openQA and let the product owners decide how they want their products be tested? If for any reason you do not see this as possible I think we are ok with "_OBSOLETE=1" by default and "_DEPRIORITIZEBUILD=1" for SLE.

Actions #9

Updated by andriinikitin about 4 years ago

Why not pass through parameters to openQA and let the product owners decide how they want their products be tested? If for any reason you do not see this as possible I think we are ok with "_OBSOLETE=1" by default and "_DEPRIORITIZEBUILD=1" for SLE.

If you didn't notice - my goal here was to understand proper default behavior, of course you can always force everyone to configure everything.

As I did mention before - what behavior do you expect when the same tests for the same build must be rescheduled? Waiting them to finish looks wrong, not sure why you ignore that question.

And if you do use such approach to stop me caring about what's going on - no problem, I can just do whatever you request here without caring about actual experience.

Actions #10

Updated by andriinikitin about 4 years ago

  • Status changed from New to Resolved
Actions #11

Updated by andriinikitin about 4 years ago

  • % Done changed from 0 to 100
Actions #12

Updated by okurz about 4 years ago

andriinikitin wrote:

Why not pass through parameters to openQA and let the product owners decide how they want their products be tested? If for any reason you do not see this as possible I think we are ok with "_OBSOLETE=1" by default and "_DEPRIORITIZEBUILD=1" for SLE.

If you didn't notice - my goal here was to understand proper default behavior, of course you can always force everyone to configure everything.

As I did mention before - what behavior do you expect when the same tests for the same build must be rescheduled? Waiting them to finish looks wrong, not sure why you ignore that question.

Well, requirements from our different users differ. To my understanding for SLE we want to have subsequent builds but are interested to have previous results finished. For openSUSE the expectation is rather: If the previous build is still not finished we must obsolete it because we do not have the means to ship the old build and also tests are expected to all finish faster as they are fewer than SLE ones.

And if you do use such approach to stop me caring about what's going on - no problem, I can just do whatever you request here without caring about actual experience.

Just saying that I don't think we can make everyone happy with a single approach. This is why openQA has the different flags and in my understanding the best and easiest we can do is to simply let ObsRsync transparently configure them.

Actions

Also available in: Atom PDF