* Implement proxyvisor API with dependent device handling
* Use the state endpoint from the API to get the full device state
* Add a deviceConfig db table to store host config separately, and allow deleting config.txt entries
* Expose RESIN_APP_NAME, RESIN_APP_RELEASE, RESIN_DEVICE_NAME_AT_INIT, RESIN_DEVICE_TYPE and RESIN_HOST_OS_VERSION env vars
* Add missing error handler on a stream in docker-utils
Log messages to PubNub are now an array instead of an object.
Each element of the array is an object with m (message), t (timestamp) and s (isSystem, optional) attributes.
Logs are sent at a specific interval (110ms, fit with some margin to PubNub's approximated 10 messages/s limit), and truncated to PubNub's 32KB limit.
If we don't persist the uuid then every time the supervisor starts it
will think it's a new device. This triggers a wipe of the local state
and also a re-load of the preloaded apps. This in turn causes multiple
instances of the preloaded apps to be left running.
Signed-off-by: Petros Angelatos <petrosagg@gmail.com>
A supervisorOfflineMode true-ish attribute in config.json will cause that:
* If unprovisioned, the supervisor won't try to provision on Resin
* The update cycle will not start as the device won't consider itself provisioned
* Logs will not be sent to pubnub
* Mixpanel events won't be tracked
* The device state won't be updated to the Resin API
This change will also make the Supervisor API work with an unprovisioned device.
- Validate the options in the YAML file
- Define bind mounts for each service as in Resin apps
- Keep the modified compose file inside the supervisor's /data folder
- Fix error reporting in the first stage of "up"
Allow users to set container restart policy using environment variables.
RESIN_APP_RESTART_POLICY sets the name of the policy, and
if policy is "on-failure", optionally, RESIN_APP_RESTART_RETRIES
sets the maximum number of retries.
More information on docker docs:
https://docs.docker.com/engine/reference/run/#restart-policies-restart
One major change we introduce here is that the default policy is set
to always while we used to have the default "no".
We validate the arguments and pass retries parameter only for the case
of "on-failure" as specified in Docker API as of v1.19.
We could let docker handle the arguments directly, gaining
forwards-compatibility with any new features, but I opted
for an implementation that is as well-defined as possible.
