Closed Bug 1055268 Opened 10 years ago Closed 10 years ago

Package Socorro

Categories

(Socorro :: Infra, task)

x86_64
Linux
task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bramwelt, Assigned: bramwelt)

Details

Currently Socorro is installed by running `deploy.sh` on a server to download and install the current version build by Jenkins.

It would be nice to have Socorro installable, as either a deb or rpm package. This would simplify to deployment process to be: download package, dpkg/rpm -i. My idea is that all of the steps in 'deploy.sh' would be moved into pre/post install scripts. pre/post remove scripts would need to be written to allow for easy downgrades/rollbacks.

After discussing this with on IRC with rhelmer, we came to a couple of conclusions. To fit the classic view of how software is built and packaged, two things should change with the Makefile.
 1) `make` should build the project. Currently what 'install.sh' does.
 2) `PREFIX=.. make install` should create a deb or rpm created in the project directory, setting the root of files to PREFIX.

Note: The use of "PREFIX" here is different than how the current used in 'install.sh'. There it is more of a build directory, where PREFIX is classically used to define the root directory a project will get installed to.

Ex. PREFIX=/opt/socorro, when installed would contain: /opt/socorro/socorro-virtualenv, and /opt/socorro/application
Assignee: nobody → tbramwell
Sorry silly questions/clarifications:

(In reply to Trevor Bramwell :bramwelt from comment #0)
> Currently Socorro is installed by running `deploy.sh` on a server to
> download and install the current version build by Jenkins.
> 
> It would be nice to have Socorro installable, as either a deb or rpm
> package. This would simplify to deployment process to be: download package,
> dpkg/rpm -i. My idea is that all of the steps in 'deploy.sh' would be moved
> into pre/post install scripts. pre/post remove scripts would need to be
> written to allow for easy downgrades/rollbacks.
> 
> After discussing this with on IRC with rhelmer, we came to a couple of
> conclusions. To fit the classic view of how software is built and packaged,
> two things should change with the Makefile.
>  1) `make` should build the project. Currently what 'install.sh' does.

So would this populate the "./build" directory with binaries, virtualenv etc?

>  2) `PREFIX=.. make install` should create a deb or rpm created in the
> project directory, setting the root of files to PREFIX.

Wouldn't this be what the debian/rules (deb) or SPEC file (rpm) does - that is, call "PREFIX=(chroot) make install" and then build the package based on the chroot?

If it actually makes the packages I'd call it something like "make package" or "make rpm"/"make deb" etc, but that's all probably overkill... seems like packaging could be run directly.
(In reply to Robert Helmer [:rhelmer] from comment #1)
> So would this populate the "./build" directory with binaries, virtualenv etc?

Correct. Running `make` by itself would create `builds/socorro` and copy 
in the virtualenv, configs, application, wsgi files, webapp, stackwalker, etc.
Exactly why `install.sh` does currently with changes to the destination path
under `builds/socorro`.

If you want to change the build directory, it would be:

  $ export BUILD_DIR=/tmp/socorro
  $ make

> >  2) `PREFIX=.. make install` should create a deb or rpm created in the
> > project directory, setting the root of files to PREFIX.
> 
> Wouldn't this be what the debian/rules (deb) or SPEC file (rpm) does - that
> is, call "PREFIX=(chroot) make install" and then build the package based on
> the chroot?

Yup. The default PREFIX ('/data/socorro') would make the package look like:
 /data/socorro/socorro-virtualenv
 /data/socorro/application
Setting the PREFIX to something else (like '/usr/local') would look like:
 /usr/local/socorro-virtualenv
 /usr/local/application

> If it actually makes the packages I'd call it something like "make package"
> or "make rpm"/"make deb" etc, but that's all probably overkill... seems like
> packaging could be run directly.

make package could be easily added later to call 'script/package.sh', but the whole point of a build ('build.sh') is a package comes out ready for distribution.
All makes sense to me, thanks!
Commits pushed to master at https://github.com/mozilla/socorro

https://github.com/mozilla/socorro/commit/fc91098c76d80f620b0658be576b54c917a3d93f
Add 'package' make target.

Like, 'make install' this will not currently work on it's own without
environment variables being set first.

fix bug 1055268

https://github.com/mozilla/socorro/commit/c654b6182d8b3e47103f8aff0603e41d0703ac93
Merge pull request #2323 from bramwelt/fix-bug-1055268-package-socorro-2

fix bug 1055268 - Package Socorro
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 101
You need to log in before you can comment on or make changes to this bug.