balena-supervisor/package.json

60 lines
1.7 KiB
JSON
Raw Normal View History

2013-06-01 18:34:38 +00:00
{
"name": "resin-supervisor",
"description": "This is resin.io's Supervisor, a program that runs on IoT devices and has the task of running user Apps (which are Docker containers), and updating them as Resin's API informs it to.",
2017-08-28 20:04:36 +00:00
"version": "6.2.4",
"license": "Apache-2.0",
"repository": {
"type": "git",
"url": "https://github.com/resin-io/resin-supervisor.git"
},
"scripts": {
2016-06-16 15:10:20 +00:00
"start": "./entry.sh",
"build": "webpack --optimize-minimize",
"build-no-optimize": "webpack",
"lint": "resin-lint src/",
"versionist": "versionist"
},
"dependencies": {
"mkfifo": "^0.1.5",
"sqlite3": "^3.1.0"
},
"engines": {
"node": "^6.5.0"
},
"devDependencies": {
"JSONStream": "^1.1.2",
2015-02-27 19:35:20 +00:00
"blinking": "~0.0.2",
"bluebird": "^3.5.0",
2015-03-03 13:55:14 +00:00
"body-parser": "^1.12.0",
"buffer-equal-constant-time": "^1.0.1",
"coffee-loader": "^0.7.3",
"coffee-script": "~1.11.0",
Try to resume the download of a delta if it fails due to flaky network Applying a delta update consists of two parts: 1. The request to the delta server for the delta payload (an rsync batch file, plus some prepended Docker metadata). The response is a redirect to a URL that contains the delta (currently S3). 2. The request for the actual download of the delta. The response is streamed directly to rsync, which applies it onto the mounted root filesystem of the final image. The first step may take a while as it may trigger the generation of the delta if the request is the first one for this combination of src/dest image and the images are large. If the request times out, either because of the delta server taking too long to respond or bad network, the Supervisor automatically schedules a retry to be performed after a while. Currently, similar behaviour applies to the second step as well -- if the request fails, we immediately bail out and the Supervisor schedules a retry of the whole process (i.e. from step 1). But in this case it means we might have downloaded and applied some or most of the delta when a socket timeout occurs causing us to start all over again, wasting time and bandwidth. This commit splits the process into the two discreet steps and improves the behaviour on the second step. Specifically: - makes the Supervisor try to resume the delta download request several times before it bails out and starts the process all over again. - removes arbitrary timeout which applied over the whole process and meant some deltas would never manage to be applied (because of large delta size and low network bandwidth). - makes sure any launched rsync processes always exit and any opened streams consumed and closed. Most of the improvements are in the two dependencies linked below -- `resumable-request` and `node-docker-delta` -- and this commit merely combines the updated versions of these modules. Change-Type: minor Connects-To: #140 Depends-On: https://github.com/resin-io/node-docker-delta/pull/19 Depends-On: https://github.com/resin-io-modules/resumable-request/pull/2
2017-08-02 11:57:35 +00:00
"docker-delta": "^2.0.1",
"docker-progress": "^2.6.3",
"docker-toolbelt": "^3.0.1",
2015-03-02 17:52:12 +00:00
"event-stream": "^3.0.20",
2015-03-03 13:55:14 +00:00
"express": "^4.0.0",
2016-10-10 21:14:31 +00:00
"knex": "~0.12.3",
"lockfile": "^1.0.1",
2016-10-03 20:25:08 +00:00
"lodash": "^4.16.3",
"log-timestamp": "^0.1.2",
"memoizee": "^0.4.1",
2014-06-18 16:54:36 +00:00
"mixpanel": "0.0.20",
2015-08-26 13:40:22 +00:00
"network-checker": "~0.0.5",
"node-loader": "^0.6.0",
"null-loader": "^0.1.1",
2016-10-06 01:29:52 +00:00
"pinejs-client": "^2.4.0",
"pubnub": "^3.7.13",
"request": "^2.51.0",
Try to resume the download of a delta if it fails due to flaky network Applying a delta update consists of two parts: 1. The request to the delta server for the delta payload (an rsync batch file, plus some prepended Docker metadata). The response is a redirect to a URL that contains the delta (currently S3). 2. The request for the actual download of the delta. The response is streamed directly to rsync, which applies it onto the mounted root filesystem of the final image. The first step may take a while as it may trigger the generation of the delta if the request is the first one for this combination of src/dest image and the images are large. If the request times out, either because of the delta server taking too long to respond or bad network, the Supervisor automatically schedules a retry to be performed after a while. Currently, similar behaviour applies to the second step as well -- if the request fails, we immediately bail out and the Supervisor schedules a retry of the whole process (i.e. from step 1). But in this case it means we might have downloaded and applied some or most of the delta when a socket timeout occurs causing us to start all over again, wasting time and bandwidth. This commit splits the process into the two discreet steps and improves the behaviour on the second step. Specifically: - makes the Supervisor try to resume the delta download request several times before it bails out and starts the process all over again. - removes arbitrary timeout which applied over the whole process and meant some deltas would never manage to be applied (because of large delta size and low network bandwidth). - makes sure any launched rsync processes always exit and any opened streams consumed and closed. Most of the improvements are in the two dependencies linked below -- `resumable-request` and `node-docker-delta` -- and this commit merely combines the updated versions of these modules. Change-Type: minor Connects-To: #140 Depends-On: https://github.com/resin-io/node-docker-delta/pull/19 Depends-On: https://github.com/resin-io-modules/resumable-request/pull/2
2017-08-02 11:57:35 +00:00
"resumable-request": "^1.0.0",
"resin-lint": "^1.3.1",
"resin-register-device": "^3.0.0",
"rimraf": "^2.5.4",
"rwlock": "^5.0.0",
"semver": "^5.3.0",
"semver-regex": "^1.0.0",
"typed-error": "~0.1.0",
"versionist": "^2.8.0",
"webpack": "^3.0.0"
2014-01-01 21:03:51 +00:00
}
2017-07-12 03:06:42 +00:00
}