ExternalVendorCode/balena-supervisor
1
0
Fork 0
mirror of https://github.com/balena-os/balena-supervisor.git synced 2025-01-29 23:53:56 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity
balena-supervisor/src/device-state.coffee

449 lines
14 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'
Lock = require 'rwlock'
EventEmitter = require 'events'
fs = Promise.promisifyAll(require('fs'))
express = require 'express'
bodyParser = require 'body-parser'
network = require './network'
constants = require './lib/constants'
validation = require './lib/validation'
device = require './lib/device'
updateLock = require './lib/update-lock'
DeviceConfig = require './device-config'
Logger = require './logger'
ApplicationManager = require './application-manager'
validateLocalState = (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 !state.name? or !validation.isValidShortText(state.name)
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 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
class DeviceStateRouter
constructor: (@deviceState) ->
{ @applications } = @deviceState
@router = express.Router()
@router.use(bodyParser.urlencoded(extended: true))
@router.use(bodyParser.json())
@router.post '/v1/reboot', (req, res) =>
force = validation.checkTruthy(req.body.force)
@deviceState.executeStepAction({ action: 'reboot' }, { force })
.then (response) ->
res.status(202).json(response)
.catch (err) ->
if err instanceof updateLock.UpdatesLockedError
status = 423
else
status = 500
res.status(status).json({ Data: '', Error: err?.message or err or 'Unknown error' })
@router.post '/v1/shutdown', (req, res) =>
force = validation.checkTruthy(req.body.force)
@deviceState.executeStepAction({ action: 'shutdown' }, { force })
.then (response) ->
res.status(202).json(response)
.catch (err) ->
if err instanceof updateLock.UpdatesLockedError
status = 423
else
status = 500
res.status(status).json({ Data: '', Error: err?.message or err or 'Unknown error' })
@router.get '/v1/device', (req, res) =>
@deviceState.getStatus()
.then (state) ->
stateToSend = _.pick(state.local, [
'api_port'
'commit'
'ip_address'
'status'
'download_progress'
'os_version'
'supervisor_version'
'update_pending'
'update_failed'
'update_downloaded'
])
res.json(stateToSend)
.catch (err) ->
res.status(500).json({ Data: '', Error: err?.message or err or 'Unknown error' })
@router.use(@applications.router)
module.exports = class DeviceState extends EventEmitter
constructor: ({ @db, @config, @eventTracker }) ->
@logger = new Logger({ @eventTracker })
@deviceConfig = new DeviceConfig({ @db, @config, @logger })
@applications = new ApplicationManager({ @config, @logger, @db, @eventTracker })
@on 'error', (err) ->
console.error('Error in deviceState: ', err, err.stack)
@_currentVolatile = {}
_lock = new Lock()
@_writeLock = Promise.promisify(_lock.async.writeLock)
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
@_readLock = Promise.promisify(_lock.async.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
@stepsInProgress = []
@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
@applyContinueScheduled = false
@shuttingDown = false
@_router = new DeviceStateRouter(this)
@router = @_router.router
@on 'apply-target-state-end', (err) ->
if err?
console.log("Apply error #{err}")
else
console.log('Apply success!')
@on 'step-completed', (err) ->
if err?
console.log("Step completed with error #{err}")
else
console.log('Step success!')
@on 'step-error', (err) ->
console.log("Step error #{err}")
@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: =>
@config.getMany([ 'appUpdatePollInterval', 'offlineMode' ])
.then (conf) =>
applyTargetHealthy = conf.offlineMode or !@applyInProgress or process.hrtime(@lastApplyStart)[0] - @applications.timeSpentFetching < 2 * conf.appUpdatePollInterval
return applyTargetHealthy and @deviceConfig.gosuperHealthy
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
normaliseLegacy: =>
# When legacy apps are present, we kill their containers and migrate their /data to a named volume
# (everything else is handled by the knex migration)
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()
.map (app) =>
@applications.volumes.createFromLegacy(app.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: ->
@config.getMany([
'logsChannelSecret', 'pubnub', 'offlineMode', 'loggingEnabled', 'initialConfigSaved',
'listenPort', 'apiSecret', 'osVersion', 'osVariant', 'version', 'provisioned',
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
'resinApiEndpoint', 'connectivityCheckEnabled', 'legacyAppsPresent'
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) =>
@logger.init({
pubnub: conf.pubnub
channel: "device-#{conf.logsChannelSecret}-logs"
offlineMode: conf.offlineMode
enable: conf.loggingEnabled
})
.then =>
@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.loggingEnabled?
@logger.enable(changedConfig.loggingEnabled)
if changedConfig.apiSecret?
@reportCurrentState(api_secret: changedConfig.apiSecret)
.then =>
if validation.checkTruthy(conf.legacyAppsPresent)
@normaliseLegacy()
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 =>
@applications.init()
.then =>
if !validation.checkTruthy(conf.initialConfigSaved)
@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: ''
logs_channel: conf.logsChannelSecret
update_failed: false
update_pending: false
update_downloaded: false
)
.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
if !conf.provisioned
@loadTargetFromFile()
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
initNetworkChecks: ({ resinApiEndpoint, connectivityCheckEnabled }) =>
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
network.startConnectivityCheck resinApiEndpoint, connectivityCheckEnabled, (connected) =>
@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')
network.startIPAddressUpdate (addresses) =>
@reportCurrentState(
ip_address: addresses.join(' ')
)
, @config.constants.ipAddressUpdateInterval
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()
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
setTarget: (target) ->
validateState(target)
.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
@usingWriteLockTarget =>
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, deviceConfig, dependent
@db.transaction (trx) =>
Promise.try =>
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({ name: target.local.name }, trx)
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
@deviceConfig.setTarget(target.local.config, trx)
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
@applications.setTarget(target.local.apps, target.dependent, trx)
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
getTarget: ({ initial = 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 =>
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
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 appsStatus.commit
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')
loadTargetFromFile: (appsPath) ->
appsPath ?= constants.appsJsonPath
fs.readFileAsync(appsPath, 'utf8')
.then(JSON.parse)
.then (stateFromFile) =>
if !_.isEmpty(stateFromFile)
images = _.flatten(_.map(_.values(stateFromFile.apps), (app, appId) =>
_.map app.services, (service, serviceId) =>
svc = {
image: service.image
serviceName: service.serviceName
imageId: service.imageId
serviceId
appId
}
return @applications.imageForService(svc)
))
Promise.map images, (img) =>
@applications.images.normalise(img.name)
.then (name) =>
img.name = name
@applications.images.markAsSupervised(img)
.then =>
@setTarget({
local: stateFromFile
})
.catch (err) =>
@eventTracker.track('Loading preloaded apps failed', { error: err })
reboot: (force) =>
@applications.stopAll({ force })
.then =>
@logger.logSystemMessage('Rebooting', {}, 'Reboot')
device.reboot()
.tap =>
@emit('shutdown')
shutdown: (force) =>
@applications.stopAll({ force })
.then =>
@logger.logSystemMessage('Shutting down', {}, 'Shutdown')
device.shutdown()
.tap =>
@shuttingDown = true
@emitAsync('shutdown')
executeStepAction: (step, { force, targetState }) =>
Promise.try =>
if _.includes(@deviceConfig.validActions, step.action)
@deviceConfig.executeStepAction(step)
else if _.includes(@applications.validActions, step.action)
@applications.executeStepAction(step, { force })
else
switch step.action
when 'reboot'
@reboot(force)
when 'shutdown'
@shutdown(force)
when 'noop'
Promise.resolve()
else
throw new Error("Invalid action #{step.action}")
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
applyStepAsync: (step, { force, initial }) =>
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
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
@stepsInProgress.push(step)
setImmediate =>
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
@executeStepAction(step, { force })
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
.finally =>
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
@usingInferStepsLock =>
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
_.pullAllWith(@stepsInProgress, [ step ], _.isEqual)
.then (stepResult) =>
@emitAsync('step-completed', null, step, stepResult)
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
@continueApplyTarget({ force, 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
.catch (err) =>
@emitAsync('step-error', err, step)
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
@applyError(err, force, 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
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
applyError: (err, force, 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
@_applyingSteps = false
@applyInProgress = false
@failedUpdates += 1
@reportCurrentState(update_failed: true)
if @scheduledApply?
console.log('Updating failed, but there is already another update scheduled immediately: ', err)
else
delay = Math.min((2 ** @failedUpdates) * 500, 30000)
# If there was an error then schedule another attempt briefly in the future.
console.log('Scheduling another update attempt due to failure: ', delay, err)
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, delay, 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
@emitAsync('apply-target-state-error', err)
@emitAsync('apply-target-state-end', err)
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 = false, 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
console.log('Applying target 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
@usingInferStepsLock =>
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.join(
@getCurrentForComparison()
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
@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
(currentState, targetState) =>
@deviceConfig.getRequiredSteps(currentState, targetState, @stepsInProgress)
.then (deviceConfigSteps) =>
if !_.isEmpty(deviceConfigSteps)
return deviceConfigSteps
else
@applications.getRequiredSteps(currentState, targetState, @stepsInProgress)
)
.then (steps) =>
if _.isEmpty(steps) and _.isEmpty(@stepsInProgress)
console.log('Finished applying target state')
@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
@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)
@emitAsync('apply-target-state-end', null)
return
@reportCurrentState(update_pending: true)
Promise.map steps, (step) =>
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
@applyStepAsync(step, { force, 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
.catch (err) =>
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
@applyError(err, force, 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
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
continueApplyTarget: ({ force = false, initial = 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
if @applyContinueScheduled
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
@applyContinueScheduled = true
setTimeout( =>
@applyContinueScheduled = 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
@applyTarget({ force, 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
, 1000)
return
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
# TODO: Make this and applyTarget work purely with promises, no need to wait on events
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 }
@once 'apply-target-state-end', =>
@triggerApplyTarget(@scheduledApply)
@scheduledApply = null
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
setTimeout( =>
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()
@applyTarget({ force, 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
, delay)
return
Reference in New Issue Copy Permalink