- Get Stackato
- Why a Private PaaS?
- Features & Benefits
- Stackato by Language
- Compare Editions
- Stackato & Cloud Foundry
- Developer Tools
- Professional Services
- Commercial Support
- Code Recipes
Jan Dubois, December 14, 2011
Bugzilla is the most popular open source bug tracker, and the one we use at ActiveState for both public and private issue tracking. As such, and in the interest of dogfooding our own software, we wanted to see what it would take to deploy it to our Stackato cloud platform.
With a little investigation and reconfiguration, and with the use of Stackato's post-staging hooks, I was able to get a functional instance of Bugzilla running on Stackato.
Getting Bugzilla 4.0.2 talking PSGI on ActivePerl 5.14.2
I started off with the latest stable release of Bugzilla, which is version 4.0.2 right now. Testing that version locally with ActivePerl 5.14.2 showed that it had a conflict with the latest release of version.pm. Fortunately, this is a known issue and already has a patch in the development branch that can be applied to 4.0.2 as well.
Bugzilla is a bunch of CGI scripts, whereas Stackato prefers to run applications via the PSGI protocol. CGI scripts can be wrapped with the CGI::Emulate::PSGI module, but before attempting to do so on my own, I did a quick Google search and fortunately found that one of the Bugzilla core developers has already started this work in order too ease deployment of Bugzilla under FastCGI. The patch needed some manual tweaking to get it to apply to Bugzilla 4.0.2, but once that was done I had a version of Bugzilla that I could run under ActivePerl with 'plackup', the development PSGI server included in the Plack distribution.
Deploying Bugzilla to Stackato
Now it was time to try to deploy Bugzilla to Stackato. The first step is to create a requirements.txt file that lists all the prerequisite modules for Bugzilla from the documentation:
CGI Date::Format DateTime DateTime::TimeZone DBI DBD::mysql Digest::SHA Email::Send Email::MIME Template:: URI
Most of them are already included in ActivePerl, but it doesn't hurt to list them again. For PSGI and CGI::Emulate::PSGI support I needed to add a couple more modules:
Plack::App::WrapCGI Plack::App::URLMap CGI::Emulate::PSGI CGI::Compile
Configuring Bugzilla requires access to a database, so I decided to do this all with a little Perl script as a post-staging hook. The stackato.yml file that describes the application looks like this:
name: bugzilla # Need to specify the framework explicitly because we don't have # an app.psgi file. It is called bugzilla/app.psgi, and it will only # be created during post-staging. framework: type: perl processes: web: (cd bugzilla && $PROCESSES_WEB) hooks: post-staging: perl setup.pl # for debugging purposes only pre-running: env services: mysql: mysql-bugzilla mem: 128M
Notice the 'processes: web:' line. This is used to customize the command that launches the application, in this case to run the default uwsgi command (stored in the $PROCESSES_WEB variable) in the 'bugzilla' directory rather than the application root.
The setup.pl script basically does the following steps:
- Download Bugzilla 4.0.2. Bugzilla is not distributed via CPAN, so it cannot be installed by the requirements.txt mechanism but needs to be downloaded and unpacked explicitly.
- Apply patches for the version.pm issue and PSGI support.
- Create an automatic configuration file containing the database credentials as well as default admin information.
- Run checksetup.pl multiple times to create the initial configuration files and set up the database schema.
I've factored out a myconfig.pl file that allows end-user customization of the initial setup without having to edit setup.pl itself:
# Sample Bugzilla configuration %answer = ( ADMIN_EMAIL => 'firstname.lastname@example.org', ADMIN_PASSWORD => 'changeme', ADMIN_REALNAME => 'Sample Admin', mailfrom => "bugzilla-daemon\@stackato.local", smtpserver => "stackato.local", urlbase => 'http://bugzilla.stackato.local', );
It is not strictly necessary to change this file at all, as the settings can also be modified through the Bugzilla web interface. Just make sure you rename the admin user and change the password before making the app accessible to the outside world!
Working around one more obstacle
Unfortunately this setup doesn't quite work yet: It is not possible to log into the app with the administrator name and password. Further debugging showed that none of the HTTP POST requests would deliver the actual query data. This turns out to be an incompatibility between the CGI::Emulate::PSGI module and the uWSGI server software that Stackato uses by default to serve up PSGI applications.
I've filed this as a bug against the CGI::Emulate::PSGI module and changed the custom application start command in stackato.yml to use plackup instead of the default uwsgi command:
processes: web: (cd bugzilla && plackup --port $VCAP_APP_PORT)
As with the post-staging hooks and the run command, Stackato is the only Cloud Foundry-based platform that allows this kind of customization.
Enough talking, let's just do it
All files needed to deploy Bugzilla to your Stackato cloud are available from github. The commands needed to deploy your own instance are:
$ git clone email@example.com:ActiveState/stackato-samples.git $ cd stackato-samples/perl/bugzilla (update myconfig.pl with your email settings) $ stackato push --no-prompt
There are a number of additional prerequisites to enable optional functionality. They can be added to requirements.txt to enable the additional features. XMLRPC and JSONRPC have already been identified as being problematic under PSGI with FastCGI; I didn't check if they work with the regular setup.
Several optional features also require a background process to periodically collect stats or process inbound email. This functionality can be simulated by running the required commands externally using the `stackato run` command for now. Stackato will soon support background processes and scheduling on its own.
Subscribe to ActiveState Blogs by Email
Share this post: