vcswatch reports that
this package seems to have a new changelog entry (version
0.0.14, distribution
unstable) and new commits
in its VCS. You should consider whether it's time to make
an upload.
Here are the relevant commit messages:
commit 7551e53e2cde868b62b0a5dc89b8ec9bb7dbe8ec
Author: Thomas Goirand <zigo@debian.org>
Date: Tue Oct 13 10:47:53 2026 +0200
Report the recorded failures to the operation log
The failures which a purge records as it goes (a broken service,
an undeletable resource, a failed listing) were only visible in
the worker log: the operation log of the Vigie task jumped from
the last step straight to the joined error message of the
terminal state.
A thread-local error reporter now sits next to the abort state,
set with the callback of every public operation and inherited by
the wave threads like the abort check. _record_failure() reports
each failure through it, prefixed with a warning sign. The
stand-alone 'vgt' utility sets no reporter: its failures stay in
its console log.
commit 6ad5b8e95a7c2b80eb1dc7976059ffb8dbdf42ec
Author: Thomas Goirand <zigo@debian.org>
Date: Tue Oct 13 10:14:02 2026 +0200
Report what the final resources check waits for
The final check of purge_project() could wait for five minutes
with no news: its callback was never given to it, so the Vigie
tasks it backs showed nothing in their operation column, and
nothing in their new operation log, while it re-listed every
resource of the project round after round.
The check now takes the callback, and reports a short summary of
what is still remaining at every round (waiting for N remaining
resource(s), grouped per service:type, truncated to 255 chars:
the string also lands in the operation column of the task rows).
Each round is also an abort point, like the other step boundaries,
so that an abort asked during the wait unwinds at the next round
instead of at the next step, which may never come.
commit 597855c997f1d0a6ac4b69080fa91c1f38423800
Author: Thomas Goirand <zigo@debian.org>
Date: Thu Oct 8 00:56:30 2026 +0200
Cover the glance_images error paths
Add 112 tests for the untested branches of the glance_images modules
and sdk_compat.py, taking them all to full statement coverage: the
discovery op errors (json_get/json_project/json_find failures and
their defaults, regex and select_latest type checks, unknown ops,
Swift fetches by cloud name), the schema validation errors, the
loader edge cases (directories named like configs, non-mapping
files), the manager filters and the import timeout, the download
fallbacks on dropped connections, and the old-SDK fallbacks of
connect_cloud(), create_queued_image() and upload_image_data().
Drop the unreachable fallback_url source check of the schema: the
source-specific known-fields check already rejects the field for a
swift download, so the error could never be raised.
commit ccbb7f2e450e95f3c50bf9e12ae9d4d15c00f36e
Author: Thomas Goirand <zigo@debian.org>
Date: Thu Oct 8 00:43:45 2026 +0200
Cover the project wave error paths
Add 49 tests for the error paths of the suspend, unsuspend, and purge
waves of project.py, taking the module to full statement coverage:
the temporary user and DNS zone cleanups, the stack waits (a stack
vanishing mid-action or mid-deletion), the extra server states
(resized, rescued, paused, busy, building), the load balancer
PENDING_CREATE wait and cascade deletion, the failure recording of
the server, router, subnet, network, port, security group, image,
volume, snapshot, secret, and Swift waves, the Gnocchi deletion
failure, the surviving-snapshot guard, the empty waves, and the
request ID forwarding.
commit b267dfdcfff8e8ca034ffb328379bd4e00d6d599
Author: Thomas Goirand <zigo@debian.org>
Date: Thu Oct 8 00:35:10 2026 +0200
Cover the failure paths of the vgt commands
The vgt command handlers ran mostly on their happy paths: their
failure exits, the connection error handling and the small helpers
were untested. 16 new tests document the behavior:
- create_connection exits 1 on missing credentials, an OpenStack
configuration error and an unexpected connection error;
- validate-compute refuses a jump host without its key file,
exits 1 on an unreadable key file, loads and forwards the jump
key material, and exits 1 on a failed validation;
- validate-cleanup forwards the resource naming options;
- a failed suspension, unsuspension or purge exits 1, and an
aborted or force-quit purge exits 130;
- the Gnocchi census of an empty run reads 'nothing to delete',
the default image output falls back to '<name>.qcow2', and the
orphaned Gnocchi cleanup exits 1 on a failure.
cmd/vgt.py goes from 80% to 99% covered.
commit b1f79f48deb331e448d0a446f211ae967e93e8ad
Author: Thomas Goirand <zigo@debian.org>
Date: Wed Oct 7 18:04:20 2026 +0200
Make the project operations abortable
purge_project(), suspend_project(), unsuspend_project(),
validate_compute() and validate_cleanup() now take an optional
abort_check callable. It is held in a thread-local state, and
checked at every abort point: every step boundary (_step), every
per-resource iteration (_delete_best_effort and the inline
deletion loops) and every wait poll. When it returns True, a
TaskAborted (a BaseException, so that no operational error
handler records it as a mere resource failure) unwinds the run
to the caller.
The parallel wave threads of the purge are spawned through
_run_wave_thread, which hands them the abort check of their
operation: an abort stops every thread which is deleting things,
and the thread exits cleanly instead of printing the abort as an
unhandled exception.
'vgt project-purge' honours Ctrl-C through the same mechanism:
the first SIGINT flips the abort state (all threads stop at
their boundaries), the second restores the default handler and
kills the process. The command exits 130 when the purge was
aborted, and restores the previous handler on the way out.
An aborted validation still reverts the compute host
book-keeping (trait, aggregate, disabled state) before letting
the abort unwind.
commit 80278cc5c65ec638cb3c59009243efb85a19f745
Author: Thomas Goirand <zigo@debian.org>
Date: Wed Oct 7 17:49:54 2026 +0200
Delete the shared images even while servers use them
The shared-image branch of _purge_images refused to delete an image
while any server of the cloud was seen using it. This raced the
parallel deletion wave: the servers it saw were the very servers of
the purged project being deleted at that moment, so the shared image
was always kept, even though nothing ties an image deletion to the
servers which boot from it — an image can be deleted before, after
or while its servers are.
Drop the server check: a shared image is now only kept while one of
its member projects still exists (a server of another project could
only boot from it through a membership, which the member check
covers), and is deleted in parallel with the rest of the wave
otherwise.
The regression test asserting the old keep-while-servers policy is
replaced by one asserting the deletion, even while a server is seen
using the image.
![[bug history graph]](https://qa.debian.org/data/bts/graphs/p/python-vigietools.png){kind=link}