Project

General

Profile

action #20420

Delete requests need to be handled better

Added by dimstar over 5 years ago. Updated over 5 years ago.

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

100%

Estimated time:

Description

every now and then, we have issues with delete requests (mainly package renames)

just these days, we had a delete request for libapr1, combined with a submit request apr (providing libapr1)

The issue is that a 'delete request' has an immediate effect on '/snpshot' - so from the moment the delete request is accepted, libapr1 is no longer available in OBS to devel projects. Depending on the build status and openQA status of the snapshot that contains 'apr', it can be lengthy to get a binary libapr1 back in place for users to consume

delete requests are not the only things causing packages to disappear: removing of a 2nd spec file has the same effect:
recently, opencv was updated; it used to contain two spec files (opencv.spec and opencv-qt5.spec). The update elminiated the Qt4 support, so opencv.spec became the qt5 version and opencv-qt5.spec was removed.
Upon checkin, osc staging accept will drop the linked package opencv-qt5 - again, causing an immediate effect on /snapshot, where opencv (the qt5 variant) will only be available with the next snapshot being published

History

#1 Updated by dimstar over 5 years ago

imho, this is something OBS should assist us with. /snapshot is not 'populated by standard means' already (there are sync jobs using obs_admin to copy from /standard to /totest and from /totest to /snapshot)

#2 Updated by dimstar over 5 years ago

Process wise, we could possibly solve it like this:

Before accepting a delete request, aggregatepac the existing binaries in the /snapshot repo

  • e.g.:

  • osc aggregatepac openSUSE:Factory pkg_to_delete openSUSE:Factory zzz_DELETED_pkg -m snapshot=snapshot,totest=totest

  • once aggregate is complete, build disable zzz_DELETED_pkg

  • accept openSUSE:Factory pkg_to_delete delete request

=> /standard loses the binaries (totest and snapshot retain them from zzz_DELETE_PKG)

once /standard is completed and moves to openQA, the binaries will be removed from /totest (by the pkg binary sync task) and then
once openQA test passes, /totest is synced to /snapshot - at this point, zzz_DELETED_pkg would have no binaries and the container could be deleted (a new bot to detect such empty containers could be written)

the name zzz_DELETED would be for 'us humans' to have all those delete requests grouped together

the same logic would apply for 'normal' delete request as well as 'deleting pkg containers of 2nd spec files'

#3 Updated by mlin7442 over 5 years ago

sounds a reasonable plan. maybe just extend ttm bot for removing temporary binary instead of new bot as it does know when the iso moves to qa and snapshot published.

#5 Updated by mlin7442 over 5 years ago

  • Category set to Development
  • Status changed from New to Resolved
  • Assignee set to mlin7442
  • % Done changed from 0 to 100

The feature is implemented and tested. What we are missing is a command to display "virtual accept delete requests", but that is not part of this ticket.

Also available in: Atom PDF