Skip to content

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

ctide 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: '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)

Acceptance Criteria

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

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

Clone this wiki locally