Up to now, there was a slim but non-zero chance that an image would be downloaded between the call to `@getTarget` inside deviceState
(which gets the target state and creates Service objects using information from available images), and the call to
`@images.getAvailable` in ApplicationManager (which is used to determine whether we should keep waiting for a download or start the
service). If this race condition happened, then the ApplicationManager would infer that a service was ready to be started (because
the image appears as available), but would have incomplete information about the service because the image wasn't available when
the Service object was created. The result would be that the service would be started, and then immediately on the next applyTarget
the ApplicationManager would try to kill it and restart it to update it with the complete information from the image.
This patch changes this behavior by ensuring that all of the additional information about the current state, which includes available images,
is gathered *before* building the current and target states that we compare. This means that if the image is downloaded after the call to getAvailable, the Service might be constructed with all the information about the image, but it won't be started until the next pass, because ApplicationManager will treat it as still downloading.
Change-type: patch
Signed-off-by: Pablo Carranza Velez <pablo@balena.io>
The move from pure CoffeeScript to TypeScript has brought a
few changes to the way transpiling happens. Previously, through
serendipity, the way `startIPAddressUpdate` was called worked
because of the binding convention pre-transpiling.
However, with the move to TypeScript, this has altered and
the assumption that a lack of parentheses would call the
method before supplying a callback into the returned function
is incorrect. The method must be specifically called first.
Connects-to: #836
Change-type: patch
Signed-off-by: Heds Simons <heds@balena.io>
When updating from old supervisors (<7.0.0), we've been so far using a fake id 1 for serviceId, imageId
and releaseId since these were not available in the old supervisor. This causes problems when the supervisor
tries to report these values to the API. Moreover, the app from the legacy supervisor has an image URL
that doesn't include the content hash - this causes the supervisor to believe the image is not really downloaded
and try to fetch it again.
To fix these issues, we add a request to the API when the supervisor starts up and detects that there's a legacy
app that needs to be normalised. We fetch the appropriate release, and use it to populate the resource ids
and the updated image URL.
This should avoid the unnecessary image download, and errors reporting target state after an update.
Change-type: patch
Signed-off-by: Pablo Carranza Velez <pablo@balena.io>
This avoids issues on provisioning where the current state
(esp. config.txt) that we want to save is retrieved without
a RESIN_ or BALENA_ prefix, causing those values to be lost.
Change-type: patch
Signed-off-by: Pablo Carranza Velez <pablo@balena.io>
i.e. if we're not provisioned or if the target state is empty (of apps), then we
read apps.json to preload. We then mark that the target state has been set to avoid
trying to preload again if we ever get an empty target state from the API.
Change-type: patch
Signed-off-by: Pablo Carranza Velez <pablo@balena.io>
They will take precedence over any existing RESIN_ variables. We strip both namespaces now
whenever we get the target values.
This also fixes preloading with a legacy config (the interface to get the config keys from
the legacy apps.json was broken).
Change-type: minor
Signed-off-by: Pablo Carranza Velez <pablo@balena.io>
The resinApiEndpoint config option existed for legacy reasons, where the
apiEndpoint was passed in via env vars, but this is no longer the case,
and the current supervisor wouldn't run on these older versions of
resinOS anymore anyway, so I've removed the references to this legacy
endpoint, as it made reasoning about offline mode weird.
Change-type: minor
Signed-off-by: Cameron Diver <cameron@resin.io>
The supervisor will now check that a source of an application matches
the current source, and only start it if so.
Change-type: patch
Closes: #658
Signed-off-by: Cameron Diver <cameron@resin.io>
* Use the correct defaults for the delta config variables that have them
* Only mount /lib/firmware and /lib/modules if they exist on the host
* hardcode-migrations.js: Nicer line separation
* APIBinder: switch to using a header for authentication, and keep credentials saved in the API clients
* Fix hrtime measurements in milliseconds
* Do not uses classes for routers
* compose: properly initialize networkMode to the first entry in networks if there is one
* Fix some details regarding defaults in validation and service
Signed-off-by: Pablo Carranza Velez <pablo@resin.io>
* Switch default dependent device type to generic
* Reduce noise in logs
* Limit to 3 simultaneous delta downloads
* Better check for deltaSource
* When checking volume dependencies, do not compare regular (non-named) volumes
* Store imageId for dependent apps, and don't report dependent images with invalid imageIds
Signed-off-by: Pablo Carranza Velez <pablo@resin.io>
* Ensure commit is only reported when update has finished
* Change default delay between actions to 100ms
* Fix envArrayToObject for cases where the env var has an equal sign
* Use shell-quote to properly parse string command and entrypoint
* Fix preloading with a legacy apps.json
Signed-off-by: Pablo Carranza Velez <pablo@resin.io>
This also changes the deviceState object to use promises instead of timeouts to schedule
applying the target state.
Signed-off-by: Pablo Carranza Velez <pablo@resin.io>
Plus several small bug fixes:
* Allow target states with apps with no release
* Fix lock override and a TypeError in compareServicesForUpdate
* Lowercase service names when doing migrations and legacy preload
* Fix deltas from scratch
Signed-off-by: Pablo Carranza Velez <pablo@resin.io>
Also several bugfixes:
* Fix VPN control, logging in deviceConfig, and action executors in proxyvisor
* Fix bug in calculation of dependencies due to fields still using snake_case
* Fix snake_case in a migration, and remove unused lib/migration.coffee
* In healthcheck, count deviceState as healthy when a fetch is in progress (as in the non-multicontainer supervisor)
* Set always as default restart policy
* Fix healthcheck, stop_grace_period and mem_limit
* Lint and reduce some cyclomatic complexities
* Namespace volumes and networks by appId, switch default network name to 'default', fix dependencies in networks and volumes, fix duplicated kill steps, fix fat arrow on provisioning
* Check that supervisor network is okay every time we're applying target state
Signed-off-by: Pablo Carranza Velez <pablo@resin.io>
Also add support for several networks per container (but with no configuration yet).
Also some bugfixes and implement healthcheck and not disabling VPN on startup.
Change-Type: major
Signed-off-by: Pablo Carranza Velez <pablo@resin.io>
Also includes various improvements and bugfixes to services and the migration from legacy /data to volumes.
The switch ti migrations involves a dirty hack for webpack to properly resolve the paths to the migrations js files - it uses an expression
that webpack can't resolve, so we hardcode it to a value and use the ContextReplacementPlugin to make that value resolve to the migrations folder.
The downsides to this approach are:
- a change in knex code would break this
- the migration code is added twice to the supervisor image: once in the migrations folder (because knex needs to loop through the directory to find the files),
and once inside app.js (because I can't make webpack treat them as external)
Signed-off-by: Pablo Carranza Velez <pablo@resin.io>
This module will take care of applying the target state for the device and reporting its current state.
The state itself is handled by two other modules, ApplicationManager and DeviceConfig. The former will take care of running applications (including the dependent ones
via its Proxyvisor), and the latter will take care of device configuration like config.txt and supervisor configuration variables.
The way state is applied differs radically from the previous approach: the old application.coffee had a big `update` function that took all of the steps from fetching the target state
to running the containers. DeviceState, instead, does an iterative process through `triggerApplyTarget` of inferring the next steps to perform towards the target state, by looking at the current state and asking the ApplicationManager and DeviceConfig for
the next steps. It then applies the next steps and every time a step is completed, it schedules another round of inferring and applying the next steps.
Special care is taken to ensure `applyTarget` is not called simultaneously more than once.
This commit also adds a "device" module to handle reboot and shutdown, and moves gosuper calls to a separate module.
The module also uses a "network" module to manage network-related parts of the device's current state: IP addresses and the connectivity check.
The module implements a "normaliseLegacy" function that allows a migration from the models from older versions of the supervisor to the multicontainer models,
so that in case of a supervisor update we can have minimal downtime and bandwidth consumption when updating to the multicontainer supervisor - this migration allows
us to avoid cleaning up images, and also allows migrating the contents of the old /data for the app.
Changelog-Entry: Infer the current state of the device when applying the target state
Change-Type: patch
Signed-off-by: Pablo Carranza Velez <pablo@resin.io>
