481477 - Productize Socorro - Phase I Install for a non Mozilla use and identify / document Install

Status: RESOLVED FIXED

(Socorro :: General, task)

Description

[Austin King [:ozten]]

The current installation process needs further documentation, automation, and possibly  changes to codebase before it can be easily used by others.

Some Mozilla product specific aspects should be factored out into configuration / setup steps.

A project / exercise to identify all of these issues would be to test our current installation instructions and log bugs against
1) Missing steps
2) Broken steps
3) Mozilla implicit information or code, which should be pulled out

Comment 1

[Samuel Sidler (old account; do not CC)]

Might work with the Songbird guys on this since I know they have their on crash-stats server setup.

Comment 2

[Philippe M. Chiasson (:gozer)]

Also worth noting is the fact that we (Mozilla Messaging) want to see if we can run our own crash-stats server for Thunderbird, so I might be a good guinea pig for going over this.

Comment 3

[Samuel Sidler (old account; do not CC)]

(In reply to comment #2)
> Also worth noting is the fact that we (Mozilla Messaging) want to see if we can
> run our own crash-stats server for Thunderbird, so I might be a good guinea pig
> for going over this.

Probably not for this bug, but I kind of wonder why you'd want to do this? Find me on IRC and let me know! (ss)

Comment 4

[Michael Morgan [:morgamic]]

Documentation updated at:
http://code.google.com/p/socorro/w/list

Comment 5

[J. Paul Reed [:preed]]

I don't know if the documentation update really is enough.

The main thing I'd like to see related to "productizing" socorro is actual releases; I've asked a few times, and the answer seems to be "just pull trunk; it's always stable."

Except, that isn't always true; I recently had to do a reinstall because I happened to pull on a day where half of various bits of code had been commented out due to some sort of merge that was going on. Huge features of socorro and breakpad just weren't working (because scripts referred to tables that didn't exist, etc.)

I can think of a few other things that would be helpful to external users of socorro, including:

-- A database management script like bugzilla has, where you can run it, and it will fix up/correct your database, and not error out if the table(s) already exist (from a previous installation)

-- A dependent package guide; Socorro requires specific versions of dependent packages (e.g. it won't work with < Postgres 8.3.2, I think); it's frustrating installing Postgres 4 times because the micro version of the database engine is relevant.

There's a lot of (admittedly pretty small) things that could be done to make this better; honestly, the largest one would be releases that are known to be stable that consumers can pull from. (I'm surprised that this doesn't already happen for Mozilla production pushes...?)

Comment 6

[Robert Helmer [:rhelmer]]

I've been working on this in separate bugs, since the summary on this one is "Phase I Install for a non Mozilla use and identify / document Install".

Specific to this bug, I think the installation is documented better now:
https://github.com/mozilla/socorro/blob/master/INSTALL

In general we're moving documentation to live alongside the code, so it's clear what version of Socorro the documentation is referring to, and it's more likely to be updated since we can enforce this during code reviews (it will be published to http://socorro.readthedocs.org/en/latest/ automatically as well).

Regarding publishing releases, we do actually use stable releases internally, and there's a bug about publishing these regularly: bug 684762

Moving forward, I think there is a lot of value in having an executable installation process that is regularly tested. In the meantime we're using puppet for development (which builds up a new Socorro install from puppet manifests):
https://github.com/rhelmer/socorro-vagrant

The Vagrant setup is based on the way Mozilla actually does installs, although it's focused on developers so it installs from source rather than using packages.

There has been a lot of interest expressed and offers to help us maintain RPM and deb packages, which I think is the way we should go in the future. This is something we can test in the vagrant VM, and use ourselves for production, and it'll make basic install one-click for most people who want to use Socorro.

Database management is tricky, since the Socorro DB schema is quite complex (and frequently undergoing major changes), in the meantime we're at least dropping the latest schema and scripts to upgrade each release in https://github.com/mozilla/socorro/tree/master/sql

So I am going to close this bug for now, since I think the install is documented and we're actively working on the other issues brought up. However, I think this could be tied together more coherently. I am going to start a tracking bug and post to the mailing list about it, since we've had a few offers to help, I'd like to carve out more concrete, less interdependent tasks for people to work on.