vcswatch reports that
this package seems to have a new changelog entry (version
0.0.7, 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 ddbab954e6d9a16fe4aa2c5750326f63d6085174
Author: Thomas Goirand <zigo@debian.org>
Date: Tue Oct 13 09:46:14 2026 +0200
Add the 'openstack vigie task log show' command
The command takes a task ID and lists its operation log rows
(timestamp, operation), oldest first. The Client gains the
task_log() method getting /v2/task/<task-id>/log, which maps a
missing task to NotFound.
commit 93dabaef8bd078277ac0b56e251867966bbe16dd
Author: Thomas Goirand <zigo@debian.org>
Date: Mon Oct 12 23:32:32 2026 +0200
Add the 'openstack vigie task retry' command
The command mirrors 'task abort': one or more task IDs, one output
row per task, and a CommandError when the API retried nothing.
The Client gains the tasks_retry() method posting the IDs to
/v2/tasks-retry.
commit 95eef629d36a1a342c2be361411029e52fa6427f
Author: Thomas Goirand <zigo@debian.org>
Date: Thu Oct 8 00:24:34 2026 +0200
Cover the client error handling, remaining methods and hooks
The failure mapping of the client, a few endpoint methods and the
osc plugin hooks had no tests. 18 new tests document the behavior:
- a 404 maps to NotFound, an API error body is forwarded in the
CommandError, a non-JSON error is formatted as 'HTTP <code>:
<reason>' and a plain exception is wrapped;
- validate_cleanup, tasks_clean, show and update hit their
endpoints, update sending an empty body without a state, and
tasks_list forwarding the state filter;
- the service set command still shows a row when the API answer is
unexpected, built from the requested state;
- the service delete and task show parsers accept their arguments;
- the purge progress printer prefixes the project name;
- the plugin builds the v2 client from the session, service type,
region and interface of the instance, and its option hook adds
--os-vigie-api-version.
The evacuate client method and command stay untested on purpose:
they are a disabled stub whose URL does not even match the API
route, to be fixed when evacuation gets implemented.
v2/client.py goes from 80% to 92% covered, the package to 98%.
commit 6d664f5eea52a986f166c33bb3f472c57a58f238
Author: Thomas Goirand <zigo@debian.org>
Date: Thu Oct 8 00:22:06 2026 +0200
Cover the service list, set and delete commands
The three service commands of the client had no tests at all, and
neither had the client methods behind them. 18 new tests document
the behavior:
- the client gets /services-list, posts the ids to
/services-delete and puts the payload to /service/<id>;
- service list shows the short columns by default and the disabled
reason with --long; an unexpected answer lists nothing;
- service set requires either --enable or --disable (argparse
refuses none and both), forwards {'enabled': True/False},
forwards the reason only when disabling, maps the long columns,
and wraps a failure in a CommandError;
- service delete shows the message, the deleted count and the
joined ids, falling back to the defaults on a sparse answer;
- setup.cfg registers the three entry points.
v2/client.py goes from 69% to 80% covered.
commit cfbdcd2ddf027d96a0dc6d28cf8c9041f5b3de7b
Author: Thomas Goirand <zigo@debian.org>
Date: Wed Oct 7 21:42:21 2026 +0200
Add --force to the task abort and delete commands
Both commands forward a force option in the body of their API
call (older APIs ignore the unknown key silently):
- 'openstack vigie task abort --force' asks the workers to
force-abort the tasks: they mark the rows aborted even when
they hold no thread for them anymore, which is the case of a
worker which restarted while its task was running;
- 'openstack vigie task delete --force' deletes the rows even
when their task is still running: a live worker notices the
deletion at its next operation report and unwinds cleanly.
TaskDeleteCommand was untested so far: its parser and its
take_action are covered now, alongside the new flag.
commit 6fdaa48ff0535d2783857972ec1113601681a005
Author: Thomas Goirand <zigo@debian.org>
Date: Wed Oct 7 18:10:01 2026 +0200
Add the 'openstack vigie task abort' command
Client.tasks_abort() POSTs the task IDs to /tasks-abort, exactly
like tasks_delete() posts to /tasks-delete.
TaskAbortCommand lists one row per task: the abort requests the
API accepted ('task_id' and 'message'), followed by the ones it
refused ('task_id' and 'error', e.g. a RabbitMQ cast failure).
When nothing could be aborted at all, the command fails with a
CommandError carrying the errors.
The command is registered in setup.cfg as 'openstack vigie task
abort', and re-exported by the plugin module.
commit 8c1a89ab49cbd71b858de5830d7e2a899bc52f34
Author: Thomas Goirand <zigo@debian.org>
Date: Wed Oct 7 16:08:53 2026 +0200
Add the 'openstack vigie purge project' command
The command takes one or more project names or IDs as positional
arguments, along with the purge options of vigietools
(--delete-project, --purge-gnocchi-resources, --force and the
repeatable --tmp-user-role), and posts them as a batch to
/v2/purge-project.
Without --wait it lists the scheduled purges and the per-project
scheduling errors in one table. With --wait it polls every task
through client.wait_for_task (printing the progress of each purge
prefixed with the project name) and shows the final state and error
message; --wait-timeout bounds each wait. When no purge could be
scheduled at all, it raises a CommandError.
The Client.purge_project method is rewritten from the old
single-project stub shape to the batch API; the setup.cfg entry
point of the command is now enabled.
![[bug history graph]](https://qa.debian.org/data/bts/graphs/p/python-vigieclient.png){kind=link}