-
Notifications
You must be signed in to change notification settings - Fork 123
As a Singly Locker owner, I want new features and bug fixes in my Locker
smurthas edited this page Aug 16, 2011
·
10 revisions
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
- 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!)
- Forrest
- Temas
- Hosting /Me Storage
- 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)
- A Singly sysadmin can (from a lxc box) run something like:
lxc-stop-all
update-code
lxc-start-all