Add a "what-would-delete-do" operation, to query the Manager about what
the deletion of a specific job would entail. For some jobs the job files
will also be deleted (if they were created with a new enough Flamenco),
otherwise they will remain untouched.
Also expand the `SocketIOJobUpdate` schema to include info about job
deletion.
Add fields to the job schemas (`SubmittedJob` and `Job`) to allow
storing the shaman checkout ID (so the Shaman checkout can be deleted
along with the job later).
Add an endpoint that mimicks the job submission endpoint, to see whether
the job survives the job compiler script. This can be used to fail early,
before actually sending files to the farm.
Add an operation `getSharedStorage` that can return the shared storage
location, adjusted for the given audience & platform. This uses the
two-way variables system to adjust the Manager's configuration.
Include a `shortversion` property in the `FlamencoVersion` schema, which
will just be the version number with the release phase (and not the git
hash, the number of commits since the last tag, and the `-dirty` suffix).
This will remove a worker by soft-deletion. Any task still assigned to
the worker will be requeued.
Note that this removal should only happen when the worker is offline, or
it will cause errors on the worker as its credentials will not be
accepted any more.
The etag prevents job submissions with old settings, when the job
compiler script has been edited. The etag is the SHA1 hash of the
`JOB_TYPE` dictionary (as defined by the JavaScript file). The hash is
computed in a way that's independent of the exact formatting in the
JavaScript file. Also the actual JS code itself is irrelevant, just the
`JOB_TYPE` dictionary is used.
The submitter's platform is used to perform two-way variable
replacement. The variables of that submitter's platform are looked up,
and their values are replaced with the variable names. This only applies
to the job's settings and metadata, and is only performed on prefixes.
For example, if the submitter's platform has a variable
`render = /shared/frames`, a job setting
`output = "/shared/frames/shot123"` will be stored as
`output = "{render}/shot123".
When a Worker gets a task of this job, `{render}` will be expanded to
the value appropriate for their platform, hence the "two-way" name.
Add examples to the `WorkerSignOn` and `WorkerStateChanged` schemas.
These will make it easier to test with SwaggerUI, as they reflect a worker
signing on with the default task types.
Change the `FlamencoVersion` schema definition so that it follows the style
of the other schema definitions:
- List properties before mentioning which are required.
- Put quotes around the property names, so that they stand out from the
other YAML keys.
The task log API endpoint was loading the entire log into RAM, then sending
it as response. This makes display in a browser also a bit harder.
The API endpoint now returns some JSON with info about the task log,
including its size and which URL can be used to download it.
Manifest task: T99730
This operation takes the platform & audience, and returns the variables
that are applicable for that combination. This can then be used by the
web frontend or by the Blender add-on to do variable replacement.
Include the worker's "last seen" timestamp in the worker summary, details,
and SocketIO updates.
This is different from the "updated" timestamp, which indicates the last
time the worker entry in the database was updated (which could also be
in response to a status change request from the web interface).
Change all API URL paths from `/api/…` to `/api/v3/…`. This ensures that
old Flamenco v2 clients/workers stop working when the new Manager is in
place. This also allows redirecting API calls based on the URL, also for
future upgrades.
