Planning Installation

Planning: Installation Strategies

The primary goal of <milestone:basic></milestone:basic> is having a good story for installation of OpenBlock at small newspapers. Our grant says "...make sure that a process is being created that can be used by technology employees even at small news organizations. This step is designed to make sure that the new installation process does not require a skill level that would require the news organization to hire an employee with new skills or retrain current employees."

There are limitations to what is feasible here, since those papers may have wildly different technology infrastructure and wildly different staff capabilities, and OpenBlock requires a pretty specific infrastructure (linux/unix/OSX, with PostGIS).

Our current efforts are leading us in two directions simultaneously:

• Cloud: For the least-technical users -- those with little or no experience

  deploying Django on *nix platforms -- we will focus on cloud
  solutions, initially focusing on providing an Amazon EC2 AMI that can be cloned and running
  in minutes.

  A cloud solution allows us to provide maximum convenience, and full control over the quality of the initially installed application and its environment, while only
  having to debug and fix it once for everybody rather than once for
  each person who tries to install it.

  We can potentially target other vendors than Amazon if we stick with only one or two base
  linux distributions (eg. ubuntu 10.10), and if it's possible to make a pre-built image
  available to our users. For example, downloadable VMWare images might be an option.
  Rackspace Cloud is probably not an option because there's no way to share images with other users.

• Manual Installation: For the most technical users, we will assume that these users are

  capable of installing and configuring Django and PostGIS, and
  simply provide instructions for how to install OpenBlock on top of
  that.

  These users want to do things in the ways they are accustomed to,
  and understand what is happening. It seems that they do not appreciate having an
  unusual installer script
  do mysterious things behind their back. Transparency and control are more
  important to this class of users than convenience.

For the middle ground, we don't try to solve for all possible cases. Users will have to pick one approach or the other.

Background

We spent some time trying to write an installer script that would work for both audiences. We found at the Boston 10/30/2010 hackathon that technical users found the script too magical and mysterious, yet it wasn't robust enough for either class of users. Getting an installer to work reliably for all possible platforms does not seem like a viable approach.

Open questions

• What cloud solutions should we target other than Amazon EC2, if any?

• What's going to be the difference between setting up a clone of the Boston demo and setting up something new?