ExternalVendorCode/balena-supervisor
1
0
Fork 0
mirror of https://github.com/balena-os/balena-supervisor.git synced 2025-02-25 11:12:47 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity
balena-supervisor/src/device-state.coffee

673 lines
23 KiB
CoffeeScript
Raw Normal View History

DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
Promise = require 'bluebird'
_ = require 'lodash'
EventEmitter = require 'events'
fs = Promise.promisifyAll(require('fs'))
express = require 'express'
bodyParser = require 'body-parser'
Fix local mode and the host-config endpoint Signed-off-by: Pablo Carranza Velez <pablo@resin.io>
2018-01-23 01:56:13 -03:00
hostConfig = require './host-config'
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
network = require './network'
Add the ability to restore volumes from a backup.tgz in the data partition Change-type: minor Signed-off-by: Pablo Carranza Velez <pablo@balena.io>
2018-12-05 23:38:58 -03:00
execAsync = Promise.promisify(require('child_process').exec)
mkdirp = Promise.promisify(require('mkdirp'))
path = require 'path'
Use rimraf package instead of handmade function Signed-off-by: Pablo Carranza Velez <pablo@balena.io>
2018-12-11 14:10:55 -03:00
rimraf = Promise.promisify(require('rimraf'))
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
constants = require './lib/constants'
validation = require './lib/validation'
Replace the gosuper component with a node module that handles communication with systemd, and stop using an init system in the supervisor container Change-Type: patch Signed-off-by: Pablo Carranza Velez <pablo@resin.io>
2018-03-16 11:01:50 -03:00
systemd = require './lib/systemd'
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
updateLock = require './lib/update-lock'
Fix bug in require for migrations for legacy preload Change-type: patch Connects-to: #573 Signed-off-by: Cameron Diver <cameron@resin.io>
2018-03-09 14:10:11 +00:00
{ singleToMulticontainerApp } = require './lib/migration'
refactor: Convert update-lock module to typescript Change-type: patch Signed-off-by: Cameron Diver <cameron@balena.io>
2018-12-13 14:01:34 +00:00
{ ENOENT, EISDIR, NotFoundError, UpdatesLockedError } = require './lib/errors'
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
refactor: Convert DeviceConfig module to typescript Change-type: patch Signed-off-by: Cameron Diver <cameron@balena.io>
2018-12-20 17:12:04 +00:00
{ DeviceConfig } = require './device-config'
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
ApplicationManager = require './application-manager'
validateLocalState = (state) ->
unmanged: Don't require a device name when setting a target state Also set a default device name of 'local', to avoid an undefined value. Change-type: patch Signed-off-by: Cameron Diver <cameron@balena.io>
2018-11-29 11:23:05 +00:00
if state.name?
throw new Error('Invalid device name') if not validation.isValidShortText(state.name)
Switch to using knex migrations to set up the database, and change the database format to use integers for ids instead of strings. 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>
2017-11-29 13:32:57 -08:00
if !state.apps? or !validation.isValidAppsObject(state.apps)
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
throw new Error('Invalid apps')
Switch to using knex migrations to set up the database, and change the database format to use integers for ids instead of strings. 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>
2017-11-29 13:32:57 -08:00
if !state.config? or !validation.isValidEnv(state.config)
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
throw new Error('Invalid device configuration')
validateDependentState = (state) ->
if state.apps? and !validation.isValidDependentAppsObject(state.apps)
throw new Error('Invalid dependent apps')
if state.devices? and !validation.isValidDependentDevicesObject(state.devices)
throw new Error('Invalid dependent devices')
validateState = Promise.method (state) ->
Switch to using knex migrations to set up the database, and change the database format to use integers for ids instead of strings. 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>
2017-11-29 13:32:57 -08:00
if !_.isObject(state)
throw new Error('State must be an object')
if !_.isObject(state.local)
throw new Error('Local state must be an object')
validateLocalState(state.local)
if state.dependent?
validateDependentState(state.dependent)
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
Support setting target state in local mode from supervisor API Change-type: minor Closes: #689 Signed-off-by: Cameron Diver <cameron@resin.io>
2018-09-28 14:32:38 +01:00
# TODO (refactor): This shouldn't be here, and instead should be part of the other
# device api stuff in ./device-api
Various bugfixes and sytlistic improvements * 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>
2018-02-13 15:23:44 -08:00
createDeviceStateRouter = (deviceState) ->
router = express.Router()
router.use(bodyParser.urlencoded(extended: true))
router.use(bodyParser.json())
Force reboots and shutdowns if lock override is enabled Closes #440 Change-Type: patch Signed-off-by: Pablo Carranza Velez <pablo@resin.io>
2018-03-15 17:01:02 -03:00
rebootOrShutdown = (req, res, action) ->
deviceState.config.get('lockOverride')
.then (lockOverride) ->
refactor: Remove unnecessary validations and casts Change-type: patch Signed-off-by: Cameron Diver <cameron@balena.io>
2019-01-09 10:04:04 +00:00
force = validation.checkTruthy(req.body.force) or lockOverride
Force reboots and shutdowns if lock override is enabled Closes #440 Change-Type: patch Signed-off-by: Pablo Carranza Velez <pablo@resin.io>
2018-03-15 17:01:02 -03:00
deviceState.executeStepAction({ action }, { force })
Various bugfixes and sytlistic improvements * 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>
2018-02-13 15:23:44 -08:00
.then (response) ->
res.status(202).json(response)
.catch (err) ->
refactor: Convert update-lock module to typescript Change-type: patch Signed-off-by: Cameron Diver <cameron@balena.io>
2018-12-13 14:01:34 +00:00
if err instanceof UpdatesLockedError
Various bugfixes and sytlistic improvements * 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>
2018-02-13 15:23:44 -08:00
status = 423
else
status = 500
res.status(status).json({ Data: '', Error: err?.message or err or 'Unknown error' })
Force reboots and shutdowns if lock override is enabled Closes #440 Change-Type: patch Signed-off-by: Pablo Carranza Velez <pablo@resin.io>
2018-03-15 17:01:02 -03:00
router.post '/v1/reboot', (req, res) ->
rebootOrShutdown(req, res, 'reboot')
Various bugfixes and sytlistic improvements * 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>
2018-02-13 15:23:44 -08:00
router.post '/v1/shutdown', (req, res) ->
Force reboots and shutdowns if lock override is enabled Closes #440 Change-Type: patch Signed-off-by: Pablo Carranza Velez <pablo@resin.io>
2018-03-15 17:01:02 -03:00
rebootOrShutdown(req, res, 'shutdown')
Various bugfixes and sytlistic improvements * 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>
2018-02-13 15:23:44 -08:00
router.get '/v1/device/host-config', (req, res) ->
hostConfig.get()
.then (conf) ->
res.json(conf)
.catch (err) ->
res.status(503).send(err?.message or err or 'Unknown error')
router.patch '/v1/device/host-config', (req, res) ->
hostConfig.patch(req.body, deviceState.config)
.then ->
res.status(200).send('OK')
.catch (err) ->
res.status(503).send(err?.message or err or 'Unknown error')
router.get '/v1/device', (req, res) ->
deviceState.getStatus()
.then (state) ->
stateToSend = _.pick(state.local, [
'api_port'
'ip_address'
'os_version'
'supervisor_version'
'update_pending'
'update_failed'
'update_downloaded'
])
if state.local.is_on__commit?
stateToSend.commit = state.local.is_on__commit
# Will produce nonsensical results for multicontainer apps...
service = _.toPairs(_.toPairs(state.local.apps)[0]?[1]?.services)[0]?[1]
if service?
stateToSend.status = service.status
# For backwards compatibility, we adapt Running to the old "Idle"
if stateToSend.status == 'Running'
stateToSend.status = 'Idle'
stateToSend.download_progress = service.download_progress
res.json(stateToSend)
.catch (err) ->
res.status(500).json({ Data: '', Error: err?.message or err or 'Unknown error' })
router.use(deviceState.applications.router)
return router
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
module.exports = class DeviceState extends EventEmitter
Implement a new logger that sends logs to the resin API, that can be used optionally instead of PubNub Change-Type: minor Signed-off-by: Pablo Carranza Velez <pablo@resin.io>
2018-02-19 17:36:57 -08:00
constructor: ({ @db, @config, @eventTracker, @logger }) ->
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
@deviceConfig = new DeviceConfig({ @db, @config, @logger })
Implement v2 API endpoints to restart and purge apps, and restart a service 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>
2018-01-19 16:31:02 -03:00
@applications = new ApplicationManager({ @config, @logger, @db, @eventTracker, deviceState: this })
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
@on 'error', (err) ->
console.error('Error in deviceState: ', err, err.stack)
@_currentVolatile = {}
refactor: Only promisify read and write locks once Change-type: patch Signed-off-by: Cameron Diver <cameron@balena.io>
2018-12-24 13:16:35 +00:00
@_writeLock = updateLock.writeLock
@_readLock = updateLock.readLock
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
@lastSuccessfulUpdate = null
@failedUpdates = 0
@applyInProgress = false
Use a supervisor0 network interface for the supervisor network API. Remove RESIN_APP_COMMIT and RESIN_APP_RELEASE env vars. 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>
2017-12-07 17:18:21 -08:00
@lastApplyStart = process.hrtime()
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
@scheduledApply = null
@shuttingDown = false
Various bugfixes and sytlistic improvements * 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>
2018-02-13 15:23:44 -08:00
@router = createDeviceStateRouter(this)
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
@on 'apply-target-state-end', (err) ->
if err?
console.log("Apply error #{err}")
else
console.log('Apply success!')
@applications.on('change', @reportCurrentState)
Use a supervisor0 network interface for the supervisor network API. Remove RESIN_APP_COMMIT and RESIN_APP_RELEASE env vars. 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>
2017-12-07 17:18:21 -08:00
healthcheck: =>
Make the failure backoff time the same as the appUpdatePollTime Change-type: patch Signed-off-by: Cameron Diver <cameron@balena.io>
2019-02-05 11:46:49 +00:00
@config.getMany([ 'unmanaged' ])
Use a supervisor0 network interface for the supervisor network API. Remove RESIN_APP_COMMIT and RESIN_APP_RELEASE env vars. 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>
2017-12-07 17:18:21 -08:00
.then (conf) =>
Various bugfixes and sytlistic improvements * 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>
2018-02-13 15:23:44 -08:00
cycleTime = process.hrtime(@lastApplyStart)
cycleTimeMs = cycleTime[0] * 1000 + cycleTime[1] / 1e6
Make the failure backoff time the same as the appUpdatePollTime Change-type: patch Signed-off-by: Cameron Diver <cameron@balena.io>
2019-02-05 11:46:49 +00:00
cycleTimeWithinInterval = cycleTimeMs - @applications.timeSpentFetching < 2 * @maxPollTime
config: Replace supervisorOfflineMode and offlineMode with unmanaged Change-type: major Signed-off-by: Cameron Diver <cameron@balena.io>
2018-12-13 14:14:15 +00:00
applyTargetHealthy = conf.unmanaged or !@applyInProgress or @applications.fetchesInProgress > 0 or cycleTimeWithinInterval
Replace the gosuper component with a node module that handles communication with systemd, and stop using an init system in the supervisor container Change-Type: patch Signed-off-by: Pablo Carranza Velez <pablo@resin.io>
2018-03-16 11:01:50 -03:00
return applyTargetHealthy
Use a supervisor0 network interface for the supervisor network API. Remove RESIN_APP_COMMIT and RESIN_APP_RELEASE env vars. 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>
2017-12-07 17:18:21 -08:00
fix: When updating from a legacy supervisor, use updated resource ids and image URL from the API 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>
2018-11-21 18:22:20 -08:00
migrateLegacyApps: (balenaApi) =>
console.log('Migrating ids for legacy app...')
@db.models('app').select()
.then (apps) =>
if apps.length == 0
console.log('No app to migrate')
return
app = apps[0]
services = JSON.parse(app.services)
# Check there's a main service, with legacy-container set
if services.length != 1
console.log("App doesn't have a single service, ignoring")
return
service = services[0]
if !service.labels['io.resin.legacy-container'] and !service.labels['io.balena.legacy-container']
console.log('Service is not marked as legacy, ignoring')
return
console.log("Getting release #{app.commit} for app #{app.appId} from API")
balenaApi.get(
resource: 'release'
options:
Update pinejs-client to pinejs-client-request 5.x Change-type: patch
2018-11-05 14:49:06 +00:00
$filter:
fix: When updating from a legacy supervisor, use updated resource ids and image URL from the API 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>
2018-11-21 18:22:20 -08:00
belongs_to__application: app.appId
commit: app.commit
status: 'success'
Update pinejs-client to pinejs-client-request 5.x Change-type: patch
2018-11-05 14:49:06 +00:00
$expand:
fix: When updating from a legacy supervisor, use updated resource ids and image URL from the API 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>
2018-11-21 18:22:20 -08:00
contains__image: [ 'image' ]
)
.then (releasesFromAPI) =>
if releasesFromAPI.length == 0
throw new Error('No compatible releases found in API')
release = releasesFromAPI[0]
releaseId = release.id
image = release.contains__image[0].image[0]
imageId = image.id
serviceId = image.is_a_build_of__service.__id
imageUrl = image.is_stored_at__image_location
if image.content_hash
imageUrl += "@#{image.content_hash}"
console.log("Found a release with releaseId #{releaseId}, imageId #{imageId}, serviceId #{serviceId}")
console.log("Image location is #{imageUrl}")
Promise.join(
@applications.docker.getImage(service.image).inspect().catchReturn(NotFoundError, null)
@db.models('image').where(name: service.image).select()
(imageFromDocker, imagesFromDB) =>
@db.transaction (trx) ->
Promise.try ->
if imagesFromDB.length > 0
console.log('Deleting existing image entry in db')
trx('image').where(name: service.image).del()
else
console.log('No image in db to delete')
.then ->
if imageFromDocker?
console.log('Inserting fixed image entry in db')
newImage = {
name: imageUrl,
appId: app.appId,
serviceId: serviceId,
serviceName: service.serviceName,
imageId: imageId,
releaseId: releaseId,
dependent: 0
dockerImageId: imageFromDocker.Id
}
trx('image').insert(newImage)
else
console.log('Image is not downloaded, so not saving it to db')
.then ->
service.image = imageUrl
service.serviceID = serviceId
service.imageId = imageId
service.releaseId = releaseId
delete service.labels['io.resin.legacy-container']
delete service.labels['io.balena.legacy-container']
app.services = JSON.stringify([ service ])
app.releaseId = releaseId
console.log('Updating app entry in db')
trx('app').update(app).where({ appId: app.appId })
)
normaliseLegacy: (balenaApi) =>
Switch to using knex migrations to set up the database, and change the database format to use integers for ids instead of strings. 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>
2017-11-29 13:32:57 -08:00
# When legacy apps are present, we kill their containers and migrate their /data to a named volume
fix: When updating from a legacy supervisor, use updated resource ids and image URL from the API 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>
2018-11-21 18:22:20 -08:00
# We also need to get the releaseId, serviceId, imageId and updated image URL
@migrateLegacyApps(balenaApi)
.then =>
console.log('Killing legacy containers')
@applications.services.killAllLegacy()
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
.then =>
Switch to using knex migrations to set up the database, and change the database format to use integers for ids instead of strings. 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>
2017-11-29 13:32:57 -08:00
console.log('Migrating legacy app volumes')
@applications.getTargetApps()
Convert object to array when normalising legacy target apps Change-type: patch Connects-to: #567 Signed-off-by: Cameron Diver <cameron@resin.io>
2018-03-08 15:32:00 +00:00
.then(_.keys)
.map (appId) =>
@applications.volumes.createFromLegacy(appId)
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
.then =>
Switch to using knex migrations to set up the database, and change the database format to use integers for ids instead of strings. 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>
2017-11-29 13:32:57 -08:00
@config.set({ legacyAppsPresent: 'false' })
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
init: ->
Implement a new logger that sends logs to the resin API, that can be used optionally instead of PubNub Change-Type: minor Signed-off-by: Pablo Carranza Velez <pablo@resin.io>
2018-02-19 17:36:57 -08:00
@config.on 'change', (changedConfig) =>
if changedConfig.loggingEnabled?
refactor: Remove unnecessary validations and casts Change-type: patch Signed-off-by: Cameron Diver <cameron@balena.io>
2019-01-09 10:04:04 +00:00
@logger.enable(changedConfig.loggingEnabled)
Implement a new logger that sends logs to the resin API, that can be used optionally instead of PubNub Change-Type: minor Signed-off-by: Pablo Carranza Velez <pablo@resin.io>
2018-02-19 17:36:57 -08:00
if changedConfig.apiSecret?
@reportCurrentState(api_secret: changedConfig.apiSecret)
Make the failure backoff time the same as the appUpdatePollTime Change-type: patch Signed-off-by: Cameron Diver <cameron@balena.io>
2019-02-05 11:46:49 +00:00
if changedConfig.appUpdatePollInterval?
@maxPollTime = changedConfig.appUpdatePollInterval
Implement a new logger that sends logs to the resin API, that can be used optionally instead of PubNub Change-Type: minor Signed-off-by: Pablo Carranza Velez <pablo@resin.io>
2018-02-19 17:36:57 -08:00
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
@config.getMany([
logger: Use the new logging backend Change-type: minor Signed-off-by: Petros Angelatos <petrosagg@gmail.com>
2018-07-10 13:12:46 -07:00
'initialConfigSaved', 'listenPort', 'apiSecret', 'osVersion', 'osVariant',
Fix preloading in flasher images by reading apps.json if target hasn't been set 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>
2018-10-18 17:36:42 +02:00
'version', 'provisioned', 'apiEndpoint', 'connectivityCheckEnabled', 'legacyAppsPresent',
Make the failure backoff time the same as the appUpdatePollTime Change-type: patch Signed-off-by: Cameron Diver <cameron@balena.io>
2019-02-05 11:46:49 +00:00
'targetStateSet', 'unmanaged', 'appUpdatePollInterval'
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
])
.then (conf) =>
Make the failure backoff time the same as the appUpdatePollTime Change-type: patch Signed-off-by: Cameron Diver <cameron@balena.io>
2019-02-05 11:46:49 +00:00
@maxPollTime = conf.appUpdatePollInterval
fix: When updating from a legacy supervisor, use updated resource ids and image URL from the API 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>
2018-11-21 18:22:20 -08:00
@applications.init()
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
.then =>
refactor: Remove unnecessary validations and casts Change-type: patch Signed-off-by: Cameron Diver <cameron@balena.io>
2019-01-09 10:04:04 +00:00
if !conf.initialConfigSaved
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
@saveInitialConfig()
.then =>
@initNetworkChecks(conf)
console.log('Reporting initial state, supervisor version and API info')
@reportCurrentState(
api_port: conf.listenPort
api_secret: conf.apiSecret
os_version: conf.osVersion
os_variant: conf.osVariant
supervisor_version: conf.version
provisioning_progress: null
provisioning_state: ''
Some fixes in current state reporting, error handling for "container not found", plus more style improvements Also, ensure the properties argument to eventTracker.track is an object Signed-off-by: Pablo Carranza Velez <pablo@resin.io>
2018-02-22 10:57:50 -08:00
status: 'Idle'
logger: Use the new logging backend Change-type: minor Signed-off-by: Petros Angelatos <petrosagg@gmail.com>
2018-07-10 13:12:46 -07:00
logs_channel: null
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
update_failed: false
update_pending: false
update_downloaded: false
)
.then =>
Fix preloading in flasher images by reading apps.json if target hasn't been set 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>
2018-10-18 17:36:42 +02:00
@applications.getTargetApps()
.then (targetApps) =>
refactor: Remove unnecessary validations and casts Change-type: patch Signed-off-by: Cameron Diver <cameron@balena.io>
2019-01-09 10:04:04 +00:00
if !conf.provisioned or (_.isEmpty(targetApps) and !conf.targetStateSet)
Switch to using knex migrations to set up the database, and change the database format to use integers for ids instead of strings. 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>
2017-11-29 13:32:57 -08:00
@loadTargetFromFile()
Fix preloading in flasher images by reading apps.json if target hasn't been set 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>
2018-10-18 17:36:42 +02:00
.finally =>
@config.set({ targetStateSet: 'true' })
else
console.log('Skipping preloading')
if conf.provisioned and !_.isEmpty(targetApps)
# If we're in this case, it's because we've updated from an older supervisor
# and we need to mark that the target state has been set so that
# the supervisor doesn't try to preload again if in the future target
# apps are empty again (which may happen with multi-app).
@config.set({ targetStateSet: 'true' })
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
.then =>
Use a supervisor0 network interface for the supervisor network API. Remove RESIN_APP_COMMIT and RESIN_APP_RELEASE env vars. 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>
2017-12-07 17:18:21 -08:00
@triggerApplyTarget({ initial: true })
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
config: Replace supervisorOfflineMode and offlineMode with unmanaged Change-type: major Signed-off-by: Cameron Diver <cameron@balena.io>
2018-12-13 14:14:15 +00:00
initNetworkChecks: ({ apiEndpoint, connectivityCheckEnabled, unmanaged }) =>
refactor: Remove unnecessary validations and casts Change-type: patch Signed-off-by: Cameron Diver <cameron@balena.io>
2019-01-09 10:04:04 +00:00
return if unmanaged
Remove resinApiEndpoint meta-endpoint and use config.json entry instead 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>
2018-07-12 13:27:47 +01:00
network.startConnectivityCheck apiEndpoint, connectivityCheckEnabled, (connected) =>
Use a supervisor0 network interface for the supervisor network API. Remove RESIN_APP_COMMIT and RESIN_APP_RELEASE env vars. 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>
2017-12-07 17:18:21 -08:00
@connected = connected
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
@config.on 'change', (changedConfig) ->
Switch to using knex migrations to set up the database, and change the database format to use integers for ids instead of strings. 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>
2017-11-29 13:32:57 -08:00
if changedConfig.connectivityCheckEnabled?
network.enableConnectivityCheck(changedConfig.connectivityCheckEnabled)
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
console.log('Starting periodic check for IP addresses')
api: Ensure Supervisor API returns IP addresses 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>
2018-12-06 16:17:57 +00:00
network.startIPAddressUpdate() (addresses) =>
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
@reportCurrentState(
ip_address: addresses.join(' ')
)
Various bugfixes and sytlistic improvements * 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>
2018-02-13 15:23:44 -08:00
, constants.ipAddressUpdateInterval
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
saveInitialConfig: =>
@deviceConfig.getCurrent()
.then (devConf) =>
@deviceConfig.setTarget(devConf)
.then =>
@config.set({ initialConfigSaved: 'true' })
emitAsync: (ev, args...) =>
setImmediate => @emit(ev, args...)
Switch to using knex migrations to set up the database, and change the database format to use integers for ids instead of strings. 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>
2017-11-29 13:32:57 -08:00
_readLockTarget: =>
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
@_readLock('target').disposer (release) ->
release()
Switch to using knex migrations to set up the database, and change the database format to use integers for ids instead of strings. 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>
2017-11-29 13:32:57 -08:00
_writeLockTarget: =>
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
@_writeLock('target').disposer (release) ->
release()
Switch to using knex migrations to set up the database, and change the database format to use integers for ids instead of strings. 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>
2017-11-29 13:32:57 -08:00
_inferStepsLock: =>
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
@_writeLock('inferSteps').disposer (release) ->
release()
Switch to using knex migrations to set up the database, and change the database format to use integers for ids instead of strings. 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>
2017-11-29 13:32:57 -08:00
usingReadLockTarget: (fn) =>
Promise.using @_readLockTarget, -> fn()
usingWriteLockTarget: (fn) =>
Promise.using @_writeLockTarget, -> fn()
usingInferStepsLock: (fn) =>
Promise.using @_inferStepsLock, -> fn()
Support setting target state in local mode from supervisor API Change-type: minor Closes: #689 Signed-off-by: Cameron Diver <cameron@resin.io>
2018-09-28 14:32:38 +01:00
setTarget: (target, localSource = false) ->
Check against application source for target applications 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>
2018-05-18 13:27:41 +01:00
Promise.join(
state: Don't consider local mode when storing state Change-type: patch Signed-off-by: Cameron Diver <cameron@resin.io>
2018-10-11 14:28:14 +01:00
@config.get('apiEndpoint'),
Check against application source for target applications 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>
2018-05-18 13:27:41 +01:00
validateState(target),
state: Don't consider local mode when storing state Change-type: patch Signed-off-by: Cameron Diver <cameron@resin.io>
2018-10-11 14:28:14 +01:00
(apiEndpoint) =>
Check against application source for target applications 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>
2018-05-18 13:27:41 +01:00
@usingWriteLockTarget =>
# Apps, deviceConfig, dependent
@db.transaction (trx) =>
Promise.try =>
@config.set({ name: target.local.name }, trx)
.then =>
@deviceConfig.setTarget(target.local.config, trx)
.then =>
fix: Give unmanaged target states a source of 'local' Change-type: patch Signed-off-by: Cameron Diver <cameron@balena.io>
2018-12-12 13:21:03 +00:00
if localSource or not apiEndpoint
state: Don't consider local mode when storing state Change-type: patch Signed-off-by: Cameron Diver <cameron@resin.io>
2018-10-11 14:28:14 +01:00
@applications.setTarget(target.local.apps, target.dependent, 'local', trx)
Support setting target state in local mode from supervisor API Change-type: minor Closes: #689 Signed-off-by: Cameron Diver <cameron@resin.io>
2018-09-28 14:32:38 +01:00
else
@applications.setTarget(target.local.apps, target.dependent, apiEndpoint, trx)
Check against application source for target applications 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>
2018-05-18 13:27:41 +01:00
)
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
Implement v2 API endpoints to restart and purge apps, and restart a service 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>
2018-01-19 16:31:02 -03:00
getTarget: ({ initial = false, intermediate = false } = {}) =>
Switch to using knex migrations to set up the database, and change the database format to use integers for ids instead of strings. 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>
2017-11-29 13:32:57 -08:00
@usingReadLockTarget =>
Implement v2 API endpoints to restart and purge apps, and restart a service 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>
2018-01-19 16:31:02 -03:00
if intermediate
return @intermediateTarget
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
Promise.props({
local: Promise.props({
name: @config.get('name')
Use a supervisor0 network interface for the supervisor network API. Remove RESIN_APP_COMMIT and RESIN_APP_RELEASE env vars. 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>
2017-12-07 17:18:21 -08:00
config: @deviceConfig.getTarget({ initial })
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
apps: @applications.getTargetApps()
})
dependent: @applications.getDependentTargets()
})
getStatus: ->
@applications.getStatus()
.then (appsStatus) =>
theState = { local: {}, dependent: {} }
_.merge(theState.local, @_currentVolatile)
theState.local.apps = appsStatus.local
theState.dependent.apps = appsStatus.dependent
Several bugfixes: * 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>
2018-01-23 17:28:59 -08:00
if appsStatus.commit and !@applyInProgress
Switch to using knex migrations to set up the database, and change the database format to use integers for ids instead of strings. 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>
2017-11-29 13:32:57 -08:00
theState.local.is_on__commit = appsStatus.commit
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
return theState
getCurrentForComparison: ->
Promise.join(
@config.get('name')
@deviceConfig.getCurrent()
@applications.getCurrentForComparison()
@applications.getDependentState()
(name, devConfig, apps, dependent) ->
return {
local: {
name
config: devConfig
apps
}
dependent
}
)
reportCurrentState: (newState = {}) =>
_.assign(@_currentVolatile, newState)
@emitAsync('change')
Fix coffee-script lint failures
2018-11-02 14:15:01 +00:00
_convertLegacyAppsJson: (appsArray) ->
Promise.try ->
deviceConf = _.reduce(appsArray, (conf, app) ->
fix: Store and retrieve device config without namespaces 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>
2018-10-20 04:26:14 +02:00
return _.merge({}, conf, app.config)
, {})
apps = _.keyBy(_.map(appsArray, singleToMulticontainerApp), 'appId')
return { apps, config: deviceConf }
Fix preloaded apps and support legacy preloading, and fix some details in the default service when migrating Signed-off-by: Pablo Carranza Velez <pablo@resin.io>
2018-01-18 16:34:25 -03:00
Add the ability to restore volumes from a backup.tgz in the data partition Change-type: minor Signed-off-by: Pablo Carranza Velez <pablo@balena.io>
2018-12-05 23:38:58 -03:00
restoreBackup: (targetState) =>
@setTarget(targetState)
.then =>
appId = _.keys(targetState.local.apps)[0]
if !appId?
throw new Error('No appId in target state')
volumes = targetState.local.apps[appId].volumes
backupPath = path.join(constants.rootMountPoint, 'mnt/data/backup')
rimraf(backupPath) # We clear this path in case it exists from an incomplete run of this function
.then ->
mkdirp(backupPath)
.then ->
execAsync("tar -xzf backup.tgz -C #{backupPath} .", cwd: path.join(constants.rootMountPoint, 'mnt/data'))
.then ->
fs.readdirAsync(backupPath)
.then (dirContents) =>
Promise.mapSeries dirContents, (volumeName) =>
Stricter validation for backup file contents Signed-off-by: Pablo Carranza Velez <pablo@balena.io>
2018-12-10 18:04:08 -03:00
fs.statAsync(path.join(backupPath, volumeName))
.then (s) =>
if !s.isDirectory()
throw new Error("Invalid backup: #{volumeName} is not a directory")
if volumes[volumeName]?
console.log("Creating volume #{volumeName} from backup")
# If the volume exists (from a previous incomplete run of this restoreBackup), we delete it first
@applications.volumes.get({ appId, name: volumeName })
.then =>
@applications.volumes.remove({ appId, name: volumeName })
.catch(NotFoundError, _.noop)
.then =>
@applications.volumes.createFromPath({ appId, name: volumeName, config: volumes[volumeName] }, path.join(backupPath, volumeName))
else
throw new Error("Invalid backup: #{volumeName} is present in backup but not in target state")
Add the ability to restore volumes from a backup.tgz in the data partition Change-type: minor Signed-off-by: Pablo Carranza Velez <pablo@balena.io>
2018-12-05 23:38:58 -03:00
.then ->
rimraf(backupPath)
.then ->
rimraf(path.join(constants.rootMountPoint, 'mnt/data', constants.migrationBackupFile))
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
loadTargetFromFile: (appsPath) ->
Fix preloading in flasher images by reading apps.json if target hasn't been set 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>
2018-10-18 17:36:42 +02:00
console.log('Attempting to load preloaded apps...')
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
appsPath ?= constants.appsJsonPath
fs.readFileAsync(appsPath, 'utf8')
.then(JSON.parse)
deviceConfig: allow BALENA_ config variables 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>
2018-10-17 10:47:11 +02:00
.then (stateFromFile) =>
if _.isArray(stateFromFile)
Fix coffee-script lint failures
2018-11-02 14:15:01 +00:00
# This is a legacy apps.json
console.log('Legacy apps.json detected')
return @_convertLegacyAppsJson(stateFromFile)
deviceConfig: allow BALENA_ config variables 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>
2018-10-17 10:47:11 +02:00
else
return stateFromFile
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
.then (stateFromFile) =>
Pin a device to a commit when preload has a pinDevice field Change-type: minor Closes: #668 Signed-off-by: Cameron Diver <cameron@resin.io>
2018-05-30 19:22:22 +01:00
commitToPin = null
appToPin = null
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
if !_.isEmpty(stateFromFile)
Various bugfixes and sytlistic improvements * 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>
2018-02-13 15:23:44 -08:00
images = _.flatMap stateFromFile.apps, (app, appId) =>
Pin a device to a commit when preload has a pinDevice field Change-type: minor Closes: #668 Signed-off-by: Cameron Diver <cameron@resin.io>
2018-05-30 19:22:22 +01:00
# multi-app warning!
# The following will need to be changed once running multiple applications is possible
commitToPin = app.commit
appToPin = appId
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
_.map app.services, (service, serviceId) =>
svc = {
Several bugfixes: * 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>
2018-01-23 17:28:59 -08:00
imageName: service.image
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
serviceName: service.serviceName
imageId: service.imageId
serviceId
Several bugfixes: * 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>
2018-01-23 17:28:59 -08:00
releaseId: app.releaseId
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
appId
}
return @applications.imageForService(svc)
Promise.map images, (img) =>
@applications.images.normalise(img.name)
.then (name) =>
img.name = name
Fix preloaded apps and support legacy preloading, and fix some details in the default service when migrating Signed-off-by: Pablo Carranza Velez <pablo@resin.io>
2018-01-18 16:34:25 -03:00
@applications.images.save(img)
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
.then =>
Fix preloaded apps and support legacy preloading, and fix some details in the default service when migrating Signed-off-by: Pablo Carranza Velez <pablo@resin.io>
2018-01-18 16:34:25 -03:00
@deviceConfig.getCurrent()
Various bugfixes and sytlistic improvements * 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>
2018-02-13 15:23:44 -08:00
.then (deviceConf) =>
fix: Store and retrieve device config without namespaces 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>
2018-10-20 04:26:14 +02:00
@deviceConfig.formatConfigKeys(stateFromFile.config)
.then (formattedConf) =>
stateFromFile.config = _.defaults(formattedConf, deviceConf)
stateFromFile.name ?= ''
@setTarget({
local: stateFromFile
})
Pin a device to a commit when preload has a pinDevice field Change-type: minor Closes: #668 Signed-off-by: Cameron Diver <cameron@resin.io>
2018-05-30 19:22:22 +01:00
.then =>
Fix preloading in flasher images by reading apps.json if target hasn't been set 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>
2018-10-18 17:36:42 +02:00
console.log('Preloading complete')
Pin a device to a commit when preload has a pinDevice field Change-type: minor Closes: #668 Signed-off-by: Cameron Diver <cameron@resin.io>
2018-05-30 19:22:22 +01:00
if stateFromFile.pinDevice
# multi-app warning!
# The following will need to be changed once running multiple applications is possible
Fix preloading in flasher images by reading apps.json if target hasn't been set 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>
2018-10-18 17:36:42 +02:00
console.log('Device will be pinned')
Pin a device to a commit when preload has a pinDevice field Change-type: minor Closes: #668 Signed-off-by: Cameron Diver <cameron@resin.io>
2018-05-30 19:22:22 +01:00
if commitToPin? and appToPin?
@config.set
refactor: Remove unnecessary validations and casts Change-type: patch Signed-off-by: Cameron Diver <cameron@balena.io>
2019-01-09 10:04:04 +00:00
pinDevice: {
Pin a device to a commit when preload has a pinDevice field Change-type: minor Closes: #668 Signed-off-by: Cameron Diver <cameron@resin.io>
2018-05-30 19:22:22 +01:00
commit: commitToPin,
refactor: Remove unnecessary validations and casts Change-type: patch Signed-off-by: Cameron Diver <cameron@balena.io>
2019-01-09 10:04:04 +00:00
app: parseInt(appToPin, 10),
Pin a device to a commit when preload has a pinDevice field Change-type: minor Closes: #668 Signed-off-by: Cameron Diver <cameron@resin.io>
2018-05-30 19:22:22 +01:00
}
Improve UX when apps.json is not present Change-type: patch Signed-off-by: Cameron Diver <cameron@balena.io>
2018-11-27 14:09:44 +00:00
# Ensure that this is actually a file, and not an empty path
# It can be an empty path because if the file does not exist
# on host, the docker daemon creates an empty directory when
# the bind mount is added
.catch ENOENT, EISDIR, ->
console.log('No apps.json file present, skipping preload')
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
.catch (err) =>
@eventTracker.track('Loading preloaded apps failed', { error: err })
Implement v2 API endpoints to restart and purge apps, and restart a service 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>
2018-01-19 16:31:02 -03:00
reboot: (force, skipLock) =>
@applications.stopAll({ force, skipLock })
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
.then =>
@logger.logSystemMessage('Rebooting', {}, 'Reboot')
Replace the gosuper component with a node module that handles communication with systemd, and stop using an init system in the supervisor container Change-Type: patch Signed-off-by: Pablo Carranza Velez <pablo@resin.io>
2018-03-16 11:01:50 -03:00
systemd.reboot()
Various bugfixes and sytlistic improvements * 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>
2018-02-13 15:23:44 -08:00
.tap =>
@shuttingDown = true
@emitAsync('shutdown')
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
Implement v2 API endpoints to restart and purge apps, and restart a service 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>
2018-01-19 16:31:02 -03:00
shutdown: (force, skipLock) =>
@applications.stopAll({ force, skipLock })
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
.then =>
@logger.logSystemMessage('Shutting down', {}, 'Shutdown')
Replace the gosuper component with a node module that handles communication with systemd, and stop using an init system in the supervisor container Change-Type: patch Signed-off-by: Pablo Carranza Velez <pablo@resin.io>
2018-03-16 11:01:50 -03:00
systemd.shutdown()
Various bugfixes and sytlistic improvements * 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>
2018-02-13 15:23:44 -08:00
.tap =>
@shuttingDown = true
@emitAsync('shutdown')
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
Implement v2 API endpoints to restart and purge apps, and restart a service 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>
2018-01-19 16:31:02 -03:00
executeStepAction: (step, { force, initial, skipLock }) =>
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
Promise.try =>
refactor: Convert DeviceConfig module to typescript Change-type: patch Signed-off-by: Cameron Diver <cameron@balena.io>
2018-12-20 17:12:04 +00:00
if @deviceConfig.isValidAction(step.action)
Add support for init, mem_reservation, shm_size, read_only and sysctls. 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>
2017-12-11 16:35:23 -08:00
@deviceConfig.executeStepAction(step, { initial })
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
else if _.includes(@applications.validActions, step.action)
Implement v2 API endpoints to restart and purge apps, and restart a service 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>
2018-01-19 16:31:02 -03:00
@applications.executeStepAction(step, { force, skipLock })
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
else
switch step.action
when 'reboot'
Respond to reboot and shutdown endpoints with a success object Change-type: patch Closes: #607 Signed-off-by: Cameron Diver <cameron@resin.io>
2018-03-29 12:37:38 +01:00
# There isn't really a way that these methods can fail,
# and if they do, we wouldn't know about it until after
# the response has been sent back to the API. Just return
# "OK" for this and the below action
@reboot(force, skipLock).return(Data: 'OK', Error: null)
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
when 'shutdown'
Respond to reboot and shutdown endpoints with a success object Change-type: patch Closes: #607 Signed-off-by: Cameron Diver <cameron@resin.io>
2018-03-29 12:37:38 +01:00
@shutdown(force, skipLock).return(Data: 'OK', Error: null)
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
when 'noop'
Promise.resolve()
else
throw new Error("Invalid action #{step.action}")
Simplify the update logic by making fetch and kill (the only long-running actions) happen in the background, and always waiting for all actions before continuing Signed-off-by: Pablo Carranza Velez <pablo@resin.io>
2018-01-26 17:29:19 -08:00
applyStep: (step, { force, initial, intermediate, skipLock }) =>
Switch to using knex migrations to set up the database, and change the database format to use integers for ids instead of strings. 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>
2017-11-29 13:32:57 -08:00
if @shuttingDown
return
Simplify the update logic by making fetch and kill (the only long-running actions) happen in the background, and always waiting for all actions before continuing Signed-off-by: Pablo Carranza Velez <pablo@resin.io>
2018-01-26 17:29:19 -08:00
@executeStepAction(step, { force, initial, skipLock })
Various bugfixes and sytlistic improvements * 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>
2018-02-13 15:23:44 -08:00
.tapCatch (err) =>
Implement v2 API endpoints to restart and purge apps, and restart a service 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>
2018-01-19 16:31:02 -03:00
@emitAsync('step-error', err, step)
.then (stepResult) =>
@emitAsync('step-completed', null, step, stepResult)
Simplify the update logic by making fetch and kill (the only long-running actions) happen in the background, and always waiting for all actions before continuing Signed-off-by: Pablo Carranza Velez <pablo@resin.io>
2018-01-26 17:29:19 -08:00
applyError: (err, { force, initial, intermediate }) =>
Avoid failed updates causing several instances of applyTarget Signed-off-by: Pablo Carranza Velez <pablo@resin.io>
2018-01-23 11:50:43 -08:00
@emitAsync('apply-target-state-error', err)
@emitAsync('apply-target-state-end', err)
Various bugfixes and sytlistic improvements * 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>
2018-02-13 15:23:44 -08:00
if intermediate
Avoid failed updates causing several instances of applyTarget Signed-off-by: Pablo Carranza Velez <pablo@resin.io>
2018-01-23 11:50:43 -08:00
throw err
Various bugfixes and sytlistic improvements * 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>
2018-02-13 15:23:44 -08:00
@failedUpdates += 1
@reportCurrentState(update_failed: true)
if @scheduledApply?
console.log("Updating failed, but there's another update scheduled immediately: ", err)
else
Make the failure backoff time the same as the appUpdatePollTime Change-type: patch Signed-off-by: Cameron Diver <cameron@balena.io>
2019-02-05 11:46:49 +00:00
delay = Math.min((2 ** @failedUpdates) * constants.backoffIncrement, @maxPollTime)
Various bugfixes and sytlistic improvements * 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>
2018-02-13 15:23:44 -08:00
# If there was an error then schedule another attempt briefly in the future.
console.log('Scheduling another update attempt due to failure: ', delay, err)
@triggerApplyTarget({ force, delay, initial })
Implement v2 API endpoints to restart and purge apps, and restart a service 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>
2018-01-19 16:31:02 -03:00
Simplify the update logic by making fetch and kill (the only long-running actions) happen in the background, and always waiting for all actions before continuing Signed-off-by: Pablo Carranza Velez <pablo@resin.io>
2018-01-26 17:29:19 -08:00
applyTarget: ({ force = false, initial = false, intermediate = false, skipLock = false } = {}) =>
nextDelay = 200
Implement v2 API endpoints to restart and purge apps, and restart a service 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>
2018-01-19 16:31:02 -03:00
Promise.try =>
if !intermediate
@applyBlocker
.then =>
@usingInferStepsLock =>
Fix a race condition that could cause an unnecessary restart of a service immediately after download 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>
2018-12-12 20:56:14 -03:00
@applications.getExtraStateForComparison()
.then (extraState) =>
Promise.all([
@getCurrentForComparison()
@getTarget({ initial, intermediate })
])
.then ([ currentState, targetState ]) =>
Simplify the update logic by making fetch and kill (the only long-running actions) happen in the background, and always waiting for all actions before continuing Signed-off-by: Pablo Carranza Velez <pablo@resin.io>
2018-01-26 17:29:19 -08:00
@deviceConfig.getRequiredSteps(currentState, targetState)
Implement v2 API endpoints to restart and purge apps, and restart a service 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>
2018-01-19 16:31:02 -03:00
.then (deviceConfigSteps) =>
if !_.isEmpty(deviceConfigSteps)
return deviceConfigSteps
else
Fix a race condition that could cause an unnecessary restart of a service immediately after download 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>
2018-12-12 20:56:14 -03:00
@applications.getRequiredSteps(currentState, targetState, extraState, intermediate)
Implement v2 API endpoints to restart and purge apps, and restart a service 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>
2018-01-19 16:31:02 -03:00
.then (steps) =>
Simplify the update logic by making fetch and kill (the only long-running actions) happen in the background, and always waiting for all actions before continuing Signed-off-by: Pablo Carranza Velez <pablo@resin.io>
2018-01-26 17:29:19 -08:00
if _.isEmpty(steps)
@emitAsync('apply-target-state-end', null)
Implement v2 API endpoints to restart and purge apps, and restart a service 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>
2018-01-19 16:31:02 -03:00
if !intermediate
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
console.log('Finished applying target state')
Use a supervisor0 network interface for the supervisor network API. Remove RESIN_APP_COMMIT and RESIN_APP_RELEASE env vars. 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>
2017-12-07 17:18:21 -08:00
@applications.timeSpentFetching = 0
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
@failedUpdates = 0
@lastSuccessfulUpdate = Date.now()
@reportCurrentState(update_failed: false, update_pending: false, update_downloaded: false)
Implement v2 API endpoints to restart and purge apps, and restart a service 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>
2018-01-19 16:31:02 -03:00
return
if !intermediate
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
@reportCurrentState(update_pending: true)
Simplify the update logic by making fetch and kill (the only long-running actions) happen in the background, and always waiting for all actions before continuing Signed-off-by: Pablo Carranza Velez <pablo@resin.io>
2018-01-26 17:29:19 -08:00
if _.every(steps, (step) -> step.action == 'noop')
nextDelay = 1000
Implement v2 API endpoints to restart and purge apps, and restart a service 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>
2018-01-19 16:31:02 -03:00
Promise.map steps, (step) =>
Simplify the update logic by making fetch and kill (the only long-running actions) happen in the background, and always waiting for all actions before continuing Signed-off-by: Pablo Carranza Velez <pablo@resin.io>
2018-01-26 17:29:19 -08:00
@applyStep(step, { force, initial, intermediate, skipLock })
Various bugfixes and sytlistic improvements * 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>
2018-02-13 15:23:44 -08:00
.delay(nextDelay)
Implement v2 API endpoints to restart and purge apps, and restart a service 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>
2018-01-19 16:31:02 -03:00
.then =>
Simplify the update logic by making fetch and kill (the only long-running actions) happen in the background, and always waiting for all actions before continuing Signed-off-by: Pablo Carranza Velez <pablo@resin.io>
2018-01-26 17:29:19 -08:00
@applyTarget({ force, initial, intermediate, skipLock })
.catch (err) =>
@applyError(err, { force, initial, intermediate })
Implement v2 API endpoints to restart and purge apps, and restart a service 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>
2018-01-19 16:31:02 -03:00
Pause updates while purging or restarting apps, and ensure an applyTarget is triggered after the actions run Signed-off-by: Pablo Carranza Velez <pablo@resin.io>
2018-01-25 12:53:54 -08:00
pausingApply: (fn) =>
lock = =>
@_writeLock('pause').disposer (release) ->
release()
pause = =>
Promise.try =>
res = null
@applyBlocker = new Promise (resolve) ->
res = resolve
return res
.disposer (resolve) ->
resolve()
Promise.using lock(), ->
Promise.using pause(), ->
fn()
Implement v2 API endpoints to restart and purge apps, and restart a service 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>
2018-01-19 16:31:02 -03:00
resumeNextApply: =>
@applyUnblocker?()
Pause updates while purging or restarting apps, and ensure an applyTarget is triggered after the actions run Signed-off-by: Pablo Carranza Velez <pablo@resin.io>
2018-01-25 12:53:54 -08:00
return
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
Use a supervisor0 network interface for the supervisor network API. Remove RESIN_APP_COMMIT and RESIN_APP_RELEASE env vars. 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>
2017-12-07 17:18:21 -08:00
triggerApplyTarget: ({ force = false, delay = 0, initial = false } = {}) =>
DeviceState: implement a module to manage the device's target and current state 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>
2017-11-01 00:24:54 -07:00
if @applyInProgress
if !@scheduledApply?
@scheduledApply = { force, delay }
else
# If a delay has been set it's because we need to hold off before applying again,
# so we need to respect the maximum delay that has been passed
@scheduledApply.delay = Math.max(delay, @scheduledApply.delay)
@scheduledApply.force or= force
return
@applyInProgress = true
Implement v2 API endpoints to restart and purge apps, and restart a service 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>
2018-01-19 16:31:02 -03:00
Promise.delay(delay)
.then =>
Use a supervisor0 network interface for the supervisor network API. Remove RESIN_APP_COMMIT and RESIN_APP_RELEASE env vars. 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>
2017-12-07 17:18:21 -08:00
@lastApplyStart = process.hrtime()
Some fixes on migrations, dependent devices and deltas * 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>
2018-01-30 08:42:03 -08:00
console.log('Applying target state')
Use a supervisor0 network interface for the supervisor network API. Remove RESIN_APP_COMMIT and RESIN_APP_RELEASE env vars. 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>
2017-12-07 17:18:21 -08:00
@applyTarget({ force, initial })
Various bugfixes and sytlistic improvements * 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>
2018-02-13 15:23:44 -08:00
.finally =>
@applyInProgress = false
@reportCurrentState()
if @scheduledApply?
@triggerApplyTarget(@scheduledApply)
@scheduledApply = null
return null
Implement v2 API endpoints to restart and purge apps, and restart a service 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>
2018-01-19 16:31:02 -03:00
applyIntermediateTarget: (intermediateTarget, { force = false, skipLock = false } = {}) =>
@intermediateTarget = _.cloneDeep(intermediateTarget)
@applyTarget({ intermediate: true, force, skipLock })
.then =>
@intermediateTarget = null
Reference in New Issue Copy Permalink