When the worker is started with `-restart-exit-code 47` or has
`restart_exit_code=47` in `flamenco-worker.yaml`, it's marked as
'restartable'. This will enable two worker actions 'Restart
(immediately)' and 'Restart (after task is finished)' in the Manager web
interface. When a worker is asked to restart, it will exit with exit
code `47`. Of course any positive exit code can be used here.
Instead of calling `useNotifs()` from the main body of `socket-status.js`,
defer that call until the notifications are actually used.
This decouples the two Pina stores at startup, making it possible to load
`socket-status.js` from `App.vue` without conflicts.
As it was decided that the name "tags" would be better for the clarity
of the feature, all files and code named "cluster" or "worker cluster"
have been removed and replaced with "tag" and "worker tag". This is only
a name change, no other features were touched.
This addresses part of #104204.
Reviewed-on: https://projects.blender.org/studio/flamenco/pulls/104223
As a note to anyone who already ran a pre-release version of Flamenco
and configured some worker clusters, with the help of an SQLite client
you can migrate the clusters to tags. First build Flamenco Manager and
start it, to create the new database schema. Then run these SQL queries
via an sqlite commandline client:
```sql
insert into worker_tags
(id, created_at, updated_at, uuid, name, description)
select id, created_at, updated_at, uuid, name, description
from worker_clusters;
insert into worker_tag_membership (worker_tag_id, worker_id)
select worker_cluster_id, worker_id from worker_cluster_membership;
```
The support is still fairly minimal. Clusters cannot be managed via the
webapp yet, so the API has to be used directly for that. Workers can be
assigned to clusters via the webapp though.
Brave (and maybe other browseres) refuse to set the 'User-Agent' header
in XMLHTTPRequests, and are vocal about this in the debug log. Since the
OpenAPI code generator always outputs a custom 'User-Agent' header, I've
added some JS code to strip that off when constructing an API client.
If there are no jobs in the database yet, show a "get the addon" call to
action. This includes the current API URL, which can be copied by clicking
on it.
There is no feedback yet that the copy took place, though.
Remove a whole lot of `console.log()` calls. They were useful during
development, but not really suitable for production environments. Because
they also include (potentially large) objects, they can even slow down
the webapp itself.
This adds a `-wizard` CLI option to the Manager, which opens a webbrowser
and shows the First-Time Wizard to aid in configuration of Flamenco.
This is work in progress. The wizard is just one page, and doesn't save
anything yet to the configuration.
UI/UX needs improvements, but there now are some buttons to manage Workers.
They request forced status changes, so nothing lazy yet. Still have to
consider how to include that in the UI. Could probably follow the
Flamenco 2 Manager design.
A task can exist in the database but not have any log stored on disk yet.
This is now returned as `204 No Content` instead of an internal server
error.
The web interface is also adjusted to cope with this.
Show workers with their status, and allow clicking on a worker to activate
it and show its details (which currently is limited to just its ID). Does
include Vue Router handling of the active worker ID and CSS classes for
worker statuses.
This basically copies the `JobsTable` component to `workers/WorkersTable`.
The intention is that all the jobs-specific components will move into a
`jobs` subdirectory at some point.
Implement task log broadcasting via SocketIO. The logs aren't shown in the
web interface yet, but do arrive there in a Pinia store. That store is
capped at 1000 lines to keep memory requirements low-ish.
Pinia's `$patch()` function will merge the given state with the current
state, instead of doing a replacement. As a result, going from an active
job with metadata fields `A` and `B`, to a job with metadata fields `B`
and `C` would actually have fields `A`, `B`, and `C` in the Pinia store.
This is resolved by replacing the `$patch(object)` with `$patch(function)`
and having that function replace the entire job.
The selection mechanism of Tabulator was getting in the way of having nice
navigation, as it would deselect (i.e. nav to "/") before selecting the
next job (i.e. nav to "/jobs/{job-id}").
The active job is now determined by the URL and thus handled by Vue Router.
Clicking on a job simply navigates to its URL, which causes the reactive
system to load & display it.
It is still intended to get job selection for "mass actions", but that's
only possible after normal navigation is working well.
A wrapper for the generated `ApiClient` class tracks the number of running
queries. This makes it much simpler to show the "API calls pending" UI
element, regardless of which part of the webapp performs the queries.
For task scheduling this doesn't matter, but for human workflow it can be
useful to differentiate between "failed" (and should be retried) and
"cancelled" (no longer relevant).
Add a bar for "job actions", i.e. buttons that do something with the
selected job(s).
Just has one button, and it doesn't do much either, but at least the
framework for these things is here.
