Add a utility command `cmd/task-poker` that takes a job ID and changes the
status of a random task every second.
This is a development utility, to help work on the Manager's web interface
and deal with constantly-updating tasks.
Allow CORS requests from `http://localhost:<port>`. Some webbrowsers
(like Safari) are picky about hostname vs. IP addresses, and this
makes them work well with the webapp development server.
Reviewed-on: https://projects.blender.org/studio/flamenco/pulls/104385
Reviewed-by: Sybren A. Stüvel <sybren@blender.org>
When the `blender` variable has no value, Flamenco will not be able to
run Blender, which is worth emitting a warning about early on.
This required a bit of a reshuffle of the configuration loading logic, to
avoid loading things twice (and thus warning twice).
Fixes part of #104366
Fix a `nil` dereference caused by an extra check on `err`.
Co-authored-by: Nitin Rawat <shvmnrwt@gmail.com>
Reviewed-on: https://projects.blender.org/studio/flamenco/pulls/104353
Reviewed-by: Sybren A. Stüvel <sybren@blender.org>
On Linux (at least my Ubuntu) the error from finding FFmpeg wasn't
identified as a "file not found" error, and thus the more abstract
"unexpected error" message was logged.
Now any error with "file not found" in the message is handled as such,
and just produces a warning without the word "error" in there.
The Manager now loads the JavaScript files for job types on demand,
instead of caching them in memory at startup.
This will make certain calls a bit less performant, but in practice this
is around the order of a millisecond so it shouldn't matter much.
Fixes: #104349
These two tools were necessary to work around certain limitations of
earlier versions of Flamenco, and are no longer needed. And they're getting
in the way of other development.
Convert most of the code in `Makefile` to [Magefile](https://magefile.org/):
This makes it possible to build Flamenco without `make` (and the POSIX environment/commands it expect) by running:
```bash
$ go run mage.go webappInstallDeps # Only on the first build.
$ go run mage.go build
```
More efficient builds are possible with other commands, and some release-related commands still require `make`. At least the barrier to entry should be considerably lower (compared to having to install Make + Cygwin/MSYS2 on Windows).
Fix: #102633
This does not port the building of release packages, so it doesn't address #102671.
### Main Targets
| Target | Description |
|----------|---------------------------------------------------------------------------------|
| build | Build Flamenco Manager and Flamenco Worker, including the webapp and the add-on |
| check | Run unit tests, check for vulnerabilities, and run the linter |
| clean | Remove executables and other build output |
| generate | Generate code (OpenAPI and test mocks) |
### All Targets
Get these via `go run mage.go -l`:
```
Targets:
build Flamenco Manager and Flamenco Worker, including the webapp and the add-on
check Run unit tests, check for vulnerabilities, and run the linter
clean Remove executables and other build output
flamencoManager Build Flamenco Manager with the webapp and add-on ZIP embedded
flamencoManagerWithoutWebapp Only build the Flamenco Manager executable, do not rebuild the webapp
flamencoWorker Build the Flamenco Worker executable
generate code (OpenAPI and test mocks)
generateGo Generate Go code for Flamenco Manager and Worker
generateJS Generate JavaScript code for the webapp
generatePy Generate Python code for the add-on
govulncheck Check for known vulnerabilities.
staticcheck Analyse the source code.
test Run unit tests
version Show which version information would be embedded in executables
vet Run `go vet`
webappInstallDeps Use Yarn to install the webapp's NodeJS dependencies
webappStatic Build the webapp as static files that can be served
```
Co-authored-by: Mateus Abelli <mateusabelli@gmail.com>
Reviewed-on: https://projects.blender.org/studio/flamenco/pulls/104341
Do not update the website via `make update-website`. Which version of
Flamenco is published on the website is managed manually, independently of
the version in the Git repo.
Add a Worker configuration option to configure the Linux out-of-memory
behaviour. Add `oom_score_adjust=500` to `flamenco-worker.yaml` to increase
the chance that Blender gets killed when the machine runs out of memory,
instead of Flamenco Worker itself.
There's still some confusion that this is a thing to solve, whereas it can
usually safely be ignored. Reduced the log level from Warn to Info to make
the message look more innocent.
Increase the 'database open' timeout from 5 seconds to 1 minute. This
timeout also covers database migrations, and the recently added one that
adds a bunch of `NOT NULL` clauses could time out with the old 5 sec
limit.
The reason this takes long, is that SQLite doesn't directly support
adding `NOT NULL` clauses to columns. The only way to do this is to
create a new table with the desired schema, copy all data over, then
drop the old table. And with a big enough database, this takes time.
GORM has certain downsides:
- Code-first approach, where queries have to be translated to the Go code
required to execute them.
- GORM comes with its own SQLite implementation, which doesn't provide an
on-connect callback. This means that new connections cannot correctly
enable foreign key constraints, causing database consistency issues.
[SQLC](https://sqlc.dev/) solves these issues for us.
This commit doesn't fully replace GORM with SQLC, but introduces it for
a few queries. Once all queries have been converted, GORM can be removed
completely.
Send an event to the event bus whenever the farm status changes. The event
contains a farm status report (like `{status: "active"}`), and is sent to
the `/status` topic.
Note that at this moment the status is only polled every X seconds, and
thus may lag behind other events.
Add a new API operation to get the overall farm status. This is based on
the jobs and workers, and their status.
The statuses are:
- `active`: Actively working on jobs.
- `idle`: Farm could be active, but has no work to do.
- `waiting`: Work has been queued, but all workers are asleep.
- `asleep`: Farm is idle, and all workers are asleep.
- `inoperative`: Cannot work: no workers, or all are offline/error.
- `starting`: Farm is starting up.
- `unknown`: Unexpected configuration of worker and job statuses.
Send events on Manager startup & shutdown. To make this possible, events
sent to MQTT are now queued up until an MQTT server can be reached.
Otherwise the startup event would be sent before the MQTT connection was
established.
Introduce an "event bus"-like system. It's more like a fan-out
broadcaster for certain events. Instead of directly sending events to
SocketIO, they are now sent to the broker, which in turn sends it to any
registered "forwarder". Currently there is ony one forwarder, for
SocketIO.
This opens the door for a proper MQTT client that sends the same events
to an MQTT server.
Create a dedicated package `.../pkg/website` to contain constants for the
URLs of documentation, bug reporting, etc. That way it's easier to see
which parts of the website are being referred to from the Flamenco
binaries, and updates can happen in a central spot.
No functional changes.
In addition to logging `GOOS` and `GOARCH`, also log more info about the
system:
- Windows: the Windows version and edition.
- Linux: distribution, distribution version, and kernel version.
- macOS: just "macOS", until we know more about getting info there too.
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.
Rename the add-on from `flamenco3-addon.zip` to `flamenco-addon.zip`.
It still contains the same files as before, and in Blender the name of
the add-on has not changed.
Change the package base name of the Go code, from
`git.blender.org/flamenco` to `projects.blender.org/studio/flamenco`.
The old location, `git.blender.org`, has no longer been use since the
[migration to Gitea][1]. The new package names now reflect the actual
location where Flamenco is hosted.
[1]: https://code.blender.org/2023/02/new-blender-development-infrastructure/
Instead of always performing the periodic integrity check, make it possible
to disable it or run it at different intervals.
Currently for the Blender Studio it's crunch time, so the check should
really only run when there is someone looking at the system (i.e. at
restarts for upgrade purposes).
`flamenco-worker -version` now shows the 'extended' version. This is just
the application version when running a release build. Otherwise it will
be like `3.3-alpha0 (v3.2-nn-ghhhhhh)`, where `nn` is the number of commits
since the last-tagged version (`v3.2` in this example), and `ghhhhhh` is
the Git hash. This can optionally be suffixed by `-dirty` if there were
any uncommitted changes when Flamenco was built.
Due to an issue (which has been fixed in the previous commit), all tasks
in the database were deleted when starting Flamenco. This tool attempts
to recompile the job and recreate its tasks.
The statuses of the tasks are set based on the job status. Basically:
- job active → tasks queued
- job completed → tasks completed
- job cancelled / failed → tasks cancelled
- otherwise → tasks queued
To ensure that the tool is only used to create tasks from scratch, it
refuses to work on a job that still has tasks in the database.
This is a command that can be run to retroactively set the Shaman
Checkout ID of jobs, allowing the job deletion to also remove the job's
Shaman checkout directory.
This is highly experimental, and not built by default or shipped with
Flamenco releases. It's only been used once at Blender Animation Studio
to help cleaning up. Run at your own risk. Make backups first.
Implement the `deleteJob` API endpoint. Calling this endpoint will mark
the job as "deletion requested", after which it's queued for actual
deletion. This makes the API response fast, even when there is a lot of
work to do in the background.
A new background service "job deleter" keeps track of the queue of such
jobs, and performs the actual deletion. It removes:
- Shaman checkout for the job (but see below)
- Manager-local files of the job (task logs, last-rendered images)
- The job itself
The removal is done in the above order, so the job is only removed from the
database if the rest of the removal was succesful.
Shaman checkouts are only removed if the job was submitted with Flamenco
version 3.2. Earlier versions did not record enough information to reliably
do this.
Blender not being found can be reported via various errors (this should be
reworked in the 'blender finder API' at some point). `exec.ErrNotFound` is
returned when Blender cannot be found on `$PATH`, which is something that's
absolutely fine. This is now logged less dramatically.
Avoid the word "error" in logging when Blender cannot be found. Typically
these are warnings, and having the word "error" there makes people think
otherwise.
`make update-version` now also updates
`web/project-website/data/flamenco.yaml` so that the new version is
listed as the latest one on flamenco.blender.org.
Note that such a change will only be visible online after publishing the
site with `make project-website`. Be sure to only do this after the
build has been uploaded there, to avoid dead links.
Instead of sending the current process an interrupt signal, use a dedicated
channel to signal the wish to shut down. The main function responds to that
channel closing by performing the shutdown.
This solves an issue where the Worker would not cleanly shut down on
Windows when `offline` state was requested by the Manager.
When launching Flamenco from a server system with no way to open a web
browser, just ask the user to launch one. Quitting the Manager because
of this was a bit too dramatic.
Extract some code from `cmd/flamenco-manager/main.go` into `webservice.go`
in the same directory, just to make `main.go` a little smaller.
No functional changes.
Don't log the git commands in the version updater Go code. They are already
shown by the Makefile (`update-version` target), and we should only have
one set of those commands to maintain.
