Pulp on OpenShift
I thought I’d post about my experience getting Pulp running on OpenShift, and more specifically, OpenShift Origin.
First, the why. Well, I want an environment where I can run multiple instances of Pulp side by side, independent of each other. Pulp uses config files installed under /etc, extensions and plugins installed under /usr, and writes its own log files under /var. So, I initially started off by making some changes to Pulp so that it can be installed and run as any system user (e.g., non-root) and out of a root directory other than “/”. Then, I decided to take it a step further and get Pulp running on an OpenShift Origin setup. That way I can have different versions (or even feature branches) of Pulp each running as an OpenShift application in a completely isolated environment. And, I get this with only having to run 1 vm for OpenShift Origin, as opposed to 1 vm per Pulp instance.
I’m not going to go into a lot of detail about how to setup OpenShift Origin. I actually used this easy to follow blog post: http://www.krishnaraman.net/multi-node-openshift-origin-from-scratch/. I also had to add 2 patches to the OpenShift Origin source code. It was great to be able to check out the source and make the needed changes in order to support the application that I wanted to run. I forked the openshift/crankcase repository on GitHub and applied the patches in my fork. So, if you want to follow along, clone and check out the dev/slagle-mcollective branch from my GitHub fork and use that in Step 3 from that blog post to do the install.
The first patch makes it so that a client’s SSL certificate is available in your OpenShift application. Pulp needs access to the client certificate due to its custom authentication mechanism. Due to the way OpenShift requests are proxied, you don’t typically have access to the client certificate.
The second patch configures your application’s mod_wsgi to run in daemon mode instead of embedded mode. Daemon mode makes it so that all requests are handled by processes launched from the same python interpreter. Pulp starts background threads to help it with resource coordination, scheduling, and managing asynchronous call queues. In order for python’s threading module to behave consistently across requests, all of your processes need to be started from the same python interpreter.
Once I had my instance of OpenShift Origin setup, I got going on deploying the actual Pulp application. Here are the steps I followed.
Created a new app called pulpshift.
rhc app create -a pulpshift -t python-2.6
Added the mongodb cartridge (Pulp uses mongo as its datastore).
rhc app cartridge add -a pulpshift -c mongodb-2.0
Went into the git checkout of my pulpshift application and pulled from the openshift branch of Pulp’s git repository. Since these are 2 separate git repositories, it’s best to tell git a specific merge strategy to use. There is a branch for OpenShift for Pulp because I had to make a couple of additional changes that I didn’t want to push to Pulp’s master yet (namely some fixes for mongo user authentication).
git pull -s recursive -X theirs http://git.fedorahosted.org/git/pulp.git openshift
Pushed the changes to my OpenShift application.
ssh’d to my application’s gear (a gear is the isolated resource container of your OpenShift application). You can use the user@hostname portion of the git url for ssh. It will look something like:
Ran the following script to finish setting up Pulp. This script takes care of installing additional Pulp dependencies that aren’t available on the Python Package Index and some other setup tasks, like setting up the initial data in the mongo database.
python $OPENSHIFT_REPO_DIR/pulp-dev.py -I -A $USER
That’s it for setting up Pulp. You can use pulp-admin to interact with the server. You can either run it from the gear itself or from your local machine. Running it from the gear will ensure that you’re using the client libraries that match the Pulp version installed in the OpenShift application. There’s a wrapper script that needs to be used that takes care of setting up the $PYTHONPATH correctly and uses the python interpreter specific to your application (as opposed to the one installed on the OpenShift server itself). That script is at:
So, let’s say you wanted to login, add a repo for Katello (another awesome open source project), and then sync the repository:
$OPENSHIFT_REPO_DIR/playpen/pulp_top_dir/pulp-admin login -u admin -p admin
$OPENSHIFT_REPO_DIR/playpen/pulp_top_dir/pulp-admin repo create --repo-id katello-f16-x86_64 --feed http://repos.fedorapeople.org/repos/katello/katello/fedora-16/x86_64/
$OPENSHIFT_REPO_DIR/playpen/pulp_top_dir/pulp-admin repo sync run --repo-id katello-f16-x86_64
I’m pleased with this for a development setup and wanted to share it. Working with OpenShift Origin was great as well. Its feature set (and the fact that it’s open source) makes it fit nicely into what I was trying to accomplish.
Tags: linkedin, OpenShift, Pulp
Posted in Programming