This PR adds the following
* Supervisor v1 API application actions now return HTTP status code 423 when locks
are preventing the action to be performed. Previously this resulted in a
503 error
* Supervisor API v2 service actions now returns HTTP status code 423 when locks are
preventing the action to be performed. Previously, this resulted in an
exception logged by the supervisor and the API query timing out
* Supervisor API `/v2/applications/:appId/start-service` now does not
check for a lock. Lock handling in v2 actions is now performed by each
step executor
* `/v1/apps/:appId/start` now queries the target state and uses that
information to execute the start step (as v2 does). Previously start
resulted in `cannot get appId from undefined`
* Extra tests for API methods
Change-type: patch
Connects-to: #1523
Signed-off-by: Felipe Lalanne <felipe@balena.io>
During first time run of the supervisor, the target state is queried
by `reportInitialEnv`. Since this happens early on the initialization
process, this target state report is missed by any listeners and this
can lead to the initial target state not beeing applied (see #1455).
This PR ensures that target state is re-emitted if there were no
listeners setup on call to update.
Change-type: patch
Signed-off-by: Felipe Lalanne <felipe@balena.io>
Connects-to: #1455
Some endpoints filter data based on the scope of the API key
used to make the request. When in LocalMode the check was not
being made correctly and all apps were considered out of scope.
Change-type: patch
Signed-off-by: Rich Bayliss <rich@balena.io>
This paves the way for running multiple applications and storing
information related to the application against the application itself. A
couple of hacks have been added to v1 and v2 endpoints to maintain
compatability but these should eventually be removed with the addition
of a v3 api.
Change-type: minor
Signed-off-by: Cameron Diver <cameron@balena.io>
Currently, when the label `io.balena.features.balena-socket` is set,
the balena engine socket is mounted under `/run/balena-engine.sock`.
This causes a problem when using systemd inside the container, since
this service remounts `/run` and `/run/lock` as tmpfs, causing the
socket to become unavailable.
Making a mount of the socket into `/host/run` solves this issue. This is
the same approach taken with DBUS.
Change-type: patch
Signed-off-by: Felipe Lalanne <felipe@balena.io>
Connects-to: #1494
The source of truth for the device-type should be
device-type.json instead of config.json
Change-type: patch
Signed-off-by: Felipe Lalanne <felipe@balena.io>
Connects-to: #1472
A docker-compose.yml with the following structure
```
version: '2.1'
services:
app_1:
build: ./noisy-1
image: noisy1
app_2:
build: ./noisy-1
image: noisy1
app_3:
build: ./noisy-1
image: noisy1
```
Will lead to the supervisor creating multiple image database entries
with the same dockerId (this is because of how the engine handles this
particular case). This case is not handled by the removal process
leading to image pile up and increased disk usage.
Change-type: patch
Signed-off-by: Felipe Lalanne <felipe@balena.io>
Connects-to: #1434
The memory information reported by the supervisor currently
estimates the value of used memory as `MemTotal - MemFree`.
However, linux systems will try to cache and buffer as much
memory as possible, which will affect the output of `MemFree`
(from /proc/meminfo) and in consequence the memory usage seen
by the user on the dashboard, which will appear much greater than
it is.
The correct calculation should be `MemTotal - MemFree - Buffers - Cached`,
which the calculation performed by `htop` and the `free` commands.
Change-type: patch
Signed-off-by: Felipe Lalanne <felipe@balena.io>
Connects-to: #1471
With the addition of the system information feature (CPU temp) etc if
there wasn't any changes in the docker or config state of the device,
updates in system information would not be sent to the API. Now we
attempt to send data once every maxReportFrequency (although this does
not mean that we will be sending data that often, we still only send the
delta, if one exists)
Change-type: patch
Closes: #1481
Signed-off-by: Cameron Diver <cameron@balena.io>
In order to make supervisor upgrades more transparent, lets move away
from this env var since it requires a container restart any time the supervisor
is upgraded. We should ultimately move towards providing the supervisors
set of capabilities, but that can come later
Connects-to: #1447
Change-type: major
Signed-off-by: Matthew McGinn <matthew@balena.io>
Due to the singleton work, when performing migration M00005 and there
are apps with services created in the database, a deadlock occurs
during database initialization due to a circular
dependency for generating scoped keys.
Change-type: patch
Signed-off-by: Felipe Lalanne <felipe@balena.io>
Connects-to: #1468
When trying to apply SSDT overlays in Up Board, the supervisor currently
gets stuck in a loop trying to apply target state. See #1465
This was due to a bug in parsing the configuration, which lead to
the method bootConfigChangeRequired returning true when no change was
needed.
Change-type: patch
Signed-off-by: Felipe Lalanne <felipe@balena.io>
Connects-to: #1465
Each service, when requesting access to the Supervisor API, will
now get an individual key which can be scoped to specific resources.
In this iteration the default scope will be to the application that
the service belongs to.
We also have a `global` scope which is used by the cloud API when in
managed mode.
Change-type: patch
Signed-off-by: Rich Bayliss <rich@balena.io>
Due to switching to Alpine the ability to resolve mDNS
hostnames was lost. This patch overrides the lookup and
manually resolves the names.
Change-type: patch
Signed-off-by: Rich Bayliss <rich@balena.io>
We provide a local DNS server for containers to use and this
was not allowed through the firewall when enabled.
Change-type: patch
Signed-off-by: Rich Bayliss <rich@balena.io>
