This change will start the minimum backoff from 15s (up from 500ms) and
will use the appUpdatePollInterval configuration variable as the max.
Change-type: patch
Signed-off-by: Cameron Diver <cameron@balena.io>
Part of device-state refactor
Fix the wrong usage of TargetState as DeviceApplicationState
Change-type: patch
Signed-off-by: Theodor Gherzan <theodor@balena.io>
These contracts can specify an OS version and supervisor version that
they require. If any of the containers in a release have requirements
that are not met, the release is rejected, and the previous release
continues to run.
Change-type: minor
Closes: #1086
Signed-off-by: Cameron Diver <cameron@balena.io>
This also required refactoring the request library to be generated with
a promise, as we now no longer get the information synchronously.
We also cache the release info, to avoid grabbing it again within the
same runtime, which does not make sense.
Change-type: patch
Signed-off-by: Cameron Diver <cameron@balena.io>
With this change, we define a custom error handler as express middleware
which renders 503 error with JSON response that includes status and message
fields.
The handler also logs the error, so the stack can be inspected in supervisor
logs. It's also a point where we can report the error to analytics services.
This removes a bunch of error handlers written in every request handler
function. Behaviour should remain unchanged except the fact that
/healthy endpoint now returns 503 in case of failure instead of 500.
Change-type: patch
Signed-off-by: Roman Mazur <roman@balena.io>
Since we were comparing the VPN's value before adding the explicit "true", there were cases
were the VPN is off, and therefore "value" didn't match the default, so the supervisor would
create a device specific SUPERVISOR_VPN_CONTROL = true, which is unnecessary and causes issues if
users don't expect this and move the device to an app that has VPN disabled. The correct behavior
is to compare "varValue" and only create a device config var if this value differs from the default.
(This was the behavior before the TS conversion in 01ed7bb103b4df8fb0679cf858220db42d4a0b92 )
Change-type: patch
Signed-off-by: Pablo Carranza Velez <pablo@balena.io>
In local mode, we now update device status on the backend,
but omit applications info in our updates.
Closes: #959
Change-type: minor
Signed-off-by: Roman Mazur <roman@balena.io>
Also use the supervisor's own container logging monitoring code when
running livepush on the supervisor container.
Change-type: minor
Signed-off-by: Cameron Diver <cameron@balena.io>
This is a massive commit, but nothing related to runtime has actually
changed, only the lint errors have changed.
Change-type: patch
Signed-off-by: Cameron Diver <cameron@balena.io>
Even though this would never have attempted to report the state to the
api during local mode, it leaves behind artifacts which would cause the
state to be sometimes reported when exiting local mode. This would cause
the api to reject the update unecessarily.
Change-type: patch
Signed-off-by: Cameron Diver <cameron@balena.io>
We also add a catch to any errors when getting configuration, and send 503 in this case, even if it's
unlikely.
Change-type: patch
Signed-off-by: Pablo Carranza Velez <pablo@balena.io>
This commit does two related things:
* We make the poll interval a random time between 0.5 and 1.5 times the configured interval.
* We introduce the BALENA_SUPERVISOR_INSTANT_UPDATE_TRIGGER configuration variable, that defaults to true. If this variable is set
to false, then calls to /v1/update are ignored, and on startup the supervisor waits for a poll interval before getting the target state.
This will help especially on cases where there's a large number of devices on a single network. By disabling instant updates and setting a large
poll interval, we can now achieve a sitation where not all devices apply an update at the same time, which can help avoid
overwhelming the network.
Change-type: minor
Signed-off-by: Pablo Carranza Velez <pablo@balena.io>
Without this patch, if for some reason device pinning fails (e.g. connectivity goes down) or anything
interrupts the initialization after provisioning completes but before pinning is completed, after a retry
the supervisor would just skip the pinning code, leaving the device unpinned. This patch ensures that the
pinning procedure is run even if the device was already provisioned (as long as the pinning flag has been set,
of course). This matches the behavior that the CoffeeScript code had from before the TypeScript conversion.
Change-type: patch
Signed-off-by: Pablo Carranza Velez <pablo@balena.io>
Otherwise we'll keep doing the rest of the APIBinder init steps, like reporting initial config,
potentially before completing the provisioning.
Change-type: patch
Signed-off-by: Pablo Carranza Velez <pablo@balena.io>
This avoid a race condition, in which config.txt can be cleared if a target state is fetched before the
initial values have been created as config vars.
Change-type: patch
Signed-off-by: Pablo Carranza Velez <pablo@balena.io>
Non-200 errors were causing the watchdog to restart the supervisor,
which in some cases could cause a restart loop. Instead we change the
code to only treat communication failures as an error, and report status
code failures directly.
Change-type: patch
Closes: #843
Signed-off-by: Cameron Diver <cameron@balena.io>
