stx: Remove backup snapshot if it already exists
This commit avoids the issue where downloader and/or build-pkgs are interrupted abruptly using Ctrl+C (SIGINT) and leave behind an Aptly snapshot named "backup-<snapshot name>" (such as "backup-deb-local-binary"). Restarting the build afterwards does not allow recovery, because the snapshot whose backup was left behind cannot be published into an Aptly repository, and this causes the corresponding repository to be unavailable for the build. Here are the error and warning messages reported by apt-get running under schroot/sbuild, where the "deb-local-binary" Aptly repository is not found: E: Failed to fetch http://stx-deb-bld-1-stx-repomgr:80/\ deb-local-binary/dists/bullseye/main/binary-amd64/Packages \ 404 Not Found [IP: 10.98.96.147 80] E: Some index files failed to download. They have been ignored, \ or old ones used instead. W: Target Packages (main/binary-amd64/Packages) is configured \ multiple times in /etc/apt/sources.list:1 and \ /etc/apt/sources.list.d/sbuild-extra-repositories.list:1 W: Target Packages (main/binary-all/Packages) is configured \ multiple times in /etc/apt/sources.list:1 and \ /etc/apt/sources.list.d/sbuild-extra-repositories.list:1 E: apt-get update failed The fix for this issue involves checking for the existence of the backup Aptly snapshot and removing the pre-existing backup snapshot. This allows the build to rename the currently existing normal/non-backup snapshot to a backup snapshot. With this change, the __create_snapshot method is able to return True, which allows build-pkgs to publish the snapshot into a repository, recovering from the aforementioned situation. Verification: - No apparent issues observed when using downloader and when building incrementally as well as from scratch many times over the course a few weeks. - Interrupting downloader or build-pkgs abruptly no longer results in the inability to remove backup snapshots. This issue is admittedly not straightforward to reproduce by manually interrupting downloader/build-pkgs due to the timing aspect, but the issue can be simulated by creating a backup snapshot ahead of time as follows: stx shell --container repomgr \ -c 'aptly snapshot create backup-deb-local-binary \ from repo deb-local-binary' Afterwards, run the following: stx shell -c 'sudo apt update; downloader -b -s -c' Finally, run the following and observe that "apt update" fails to locate the "deb-local-binary" repository, which is also observed in golang-1.17's "sbuild" logs. Note that golang-1.17 is used as a placeholder package only. stx shell -c 'sudo apt update; build-pkgs -c -p golang-1.17' Closes-Bug: 1988344 Change-Id: Ibba84903982a1b05e154b038abec4f1215188dfa Signed-off-by: M. Vefa Bicakci <vefa.bicakci@windriver.com>
This commit is contained in:
parent
c0c89d5f51
commit
e91e6f77b7
|
@ -242,10 +242,14 @@ class Deb_aptly():
|
|||
self.logger.warning('Remove publication failed %s : %s' % (name, self.aptly.tasks.show(task.id).state))
|
||||
# Rename the snapshot if exists
|
||||
snap_list = self.aptly.snapshots.list()
|
||||
for snap in snap_list:
|
||||
if snap.name == name:
|
||||
backup_name = 'backup-' + name
|
||||
self.aptly.tasks.wait_for_task_by_id(self.aptly.snapshots.update(name, backup_name).id)
|
||||
|
||||
exists = [snap for snap in snap_list if snap.name == name]
|
||||
backup_exists = [snap for snap in snap_list if snap.name == 'backup-' + name]
|
||||
if exists:
|
||||
backup_name = 'backup-' + name
|
||||
if backup_exists:
|
||||
self.aptly.tasks.wait_for_task_by_id(self.aptly.snapshots.delete(backup_name, force=True).id)
|
||||
self.aptly.tasks.wait_for_task_by_id(self.aptly.snapshots.update(name, backup_name).id)
|
||||
|
||||
# crate a snapshot
|
||||
task = None
|
||||
|
|
Loading…
Reference in New Issue