The available worker clusters are stored on the addon preferences, to be
available across restarts of Blender. The prefs were not marked as 'dirty'
though, so Blender never actually saved them. That's now resolved.
A few minor adjustments:
- Added a note about the job type being third-party, and what that implies.
- Removed the need to use Git or the mention of symlinks, to simplify
installation instructions.
- Fixed a few markup issues.
Additions to the documentation:
- Page for collecting custom job types, with multi-pass job type.
- BAT Pack Error Message solution on Windows.
- Clarificationof two-way variable usage in jobs.
Reviewed-on: https://projects.blender.org/studio/flamenco/pulls/104202
In the 'Cluster' drop-down, change the label and tooltip of the 'No
Cluster' option. The functionality is still the same, it causes the job
to be submitted without cluster assigned. The wording now reflect
Flamenco's behaviour better, instead of describing this technical aspect.
Old: "No Cluster", "No cluster assigned, any worker can handle this job"
New: "All", "No specific cluster assigned, any worker can handle this job"
Clusters can be created without UUID now. In that case, a random one will
be generated. The cluster will be returned by the creation call, so that
the caller can know that generated UUID.
To allow more build-time configuration:
- `Makefile` will now pick up `LDFLAGS` from environment variables, and
- locations of configuration files can now be overridden with linker
options.
These are not used for regular Flamenco builds, but do allow studios to
customize where configuration files are stored.
Review: https://projects.blender.org/studio/flamenco/pulls/104200
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.
Worker Clusters can be managed via the API, workers can be assigned to
any number of clusters (if not assigned to any, they'll pick up any task).
Jobs can be submitted with a cluster ID, in which case only workers that
are in that cluster or are clusterless will pick up its tasks.
Various improvements to the logging of the job deletion:
- Reduce the log level of the "removing logs" and "removing job from
database" lines from INFO to DEBUG, so that only one line of INFO is
logged per deleted job
- Show size of the queue and the check interval in the "job deletion
queue is full" log message.
When queueing up jobs to be deleted, log how many deletions remain to be
picked up later. Once a minute the database is checked for such deletion
requests, so the next batch will be scheduled in a minute.
"rc" stands for "release candidate", which will trigger the same versioning
display as an actual release (i.e. just report the version, without the
Git hash info).
Fix these vulnerabilities:
```
Vulnerability #1: GO-2023-1572
An attacker can craft a malformed TIFF image which will consume
a significant amount of memory when passed to DecodeConfig. This
could lead to a denial of service.
More info: https://pkg.go.dev/vuln/GO-2023-1572
Module: golang.org/x/image
Found in: golang.org/x/image@v0.0.0-20191009234506-e7c1f5e7dbb8
Fixed in: golang.org/x/image@v0.5.0
Vulnerability #2: GO-2023-1571
A maliciously crafted HTTP/2 stream could cause excessive CPU
consumption in the HPACK decoder, sufficient to cause a denial
of service from a small number of small requests.
More info: https://pkg.go.dev/vuln/GO-2023-1571
Module: golang.org/x/net
Found in: golang.org/x/net@v0.5.0
Fixed in: golang.org/x/net@v0.7.0
```
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.
