As a Singly Locker owner, I want new features and bug fixes in my Locker

For a Singly hosted locker, it's desirable to have lockers always up to date with the latest stable version of the code. In order to enable this, there must be a simple, repeatable, manner in which the code can be updated in the hosted environment. Some high-level (a)spec(t)s of this:

• All code for lockers on a given lxc box should run from the same code (i.e. it should be mounted into lxc containers from the same place on the file system)
• To begin with, the update process will be manual, effectively: 'shutdown', 'git pull, 'npm install', 'startup'
• To support this the locker itself wil need a clean up of its "mutable data" into:
  • owner data (/Me, data from connectors, etc)
  • locker config (/Config, apikeys.json, config.json)
    • per environment (whole lxc box, api keys)
    • per instance (each locker, maybe they run on diff ports)
  • For now, let's KISS and combine the per-env and per-inst stuff into one, /Config

(First) Steps

• update the locker code to support /Config
  • update lockerbox to cp template config files into the /Config dir
• create simple 'lxc-stop all' and 'lxc-start all' scripts
• update mounts:
  • bind mount /var/locker
  • mount /var/Locker/Me separately for each locker (probably makes replication easier!)

Stakeholders

• Forrest
• Temas

Dependancies

• Hosting /Me Storage

Potential issues

• Seems like bad things might happen when lockers are 'lxc-stopped'
  • might endup needing a more graceful locker shutdown process (stopping scheduler, waiting for things to finish)
• What will happen when we restart ~300 lockers on a single box at once? (startup heart attack!)
• How will this affect Singly's SLA?
• This might result in some scope creep into testing infrastructure

Acceptance Criteria

• A Singly sysadmin can (from a lxc box) run something like:

lxc-stop-all
update-code
lxc-start-all

• The above commands are integrated in the singly lxc admin console and can be run from the web interface
• All lockers on that box will stop, be updated and restart (be externally accessible again)
• (Optional) updating code dumps a git HEAD build number into a file so that it can be seen somewhere
• (Very Optional) a sweet downtime page

COMPLETED

Results

• Configuration was migrated
• Updates to locker code can be run from admin console
• All lockers on that box will stop, be updated and restart
• (Bonus!) Updating code dumps a git HEAD build number into a file so that it can be seen somewhere (not yet integrated into locker UI)