Pulp 3 Developer Notes¶

This wiki page is intended for use during early development of Pulp 3. Over time, as our development practices become standard, the contents of this page should be moved into the Pulp Contributing Guide

Virtualenv installation issues¶

From time to time, I've (smyers) run into issues with the Platform components not being properly installed in the "pulp" virtualenv in vagrant on 3.0-dev. My fix for this is to run this command in the pulp repository root directory with the "pulp" virtualenv activated:

for dir in app/ common/ exceptions/ tasking/ plugin/; do pushd $dir; python setup.py develop; popd; done

I'm not sure what's causing this, but assume that the virtualenvs have some PYTHONPATH issue that prevents them from "seeing" the installed libs, or possibly there's just something missing from the dev playbook that sets all that up.

Similarly if you want to test any plugins in the platform API, they need to be installed into the "pulp" virtualenv the same way, by running python setup.py develop on the plugin's setup.py.

Migrations¶

In both platform and plugins, the data model is not complete. As a result, committing migrations to the 3.0-dev branch will result in merge/migration conflicts from pull request to pull request. The simplest solution for now is not to commit migrations to the repository.

Because User model depends on Django's auth app having been migrated, this means that you currently need to run python manage.py migrate auth before running a general python manage.py migrate to set up the pulp database.

Making migrations during development¶

Tests require migrations to run, so while we should not commit migrations to the repositories just yet, we do still need to make them. This can be done with the python manage.py makemigrations command. Apps that depend on the platform migrations existing (such as plugins) may cause errors when making migrations. To avoid these errors, platform migrations should be made prior to installing any plugins.

Once the initial migrations are created, and model changes made thereafter will require python manage.py makemigrations to be run again, following by @python manage.py migrate" so Django can apply the model changes to the database.

This is probably something we can do in the dev playbook; automating the process until we do start to commit migrations would help immensely with mitigating this annoyance.

Starting a Web Server¶

The Django development server can be started with python manage.py runserver. This will run a basic WSGI app that exposes the URLs routed in urls.py, allowing you to access the REST API.

If you're using the vagrant hostmanager plugin, you can easily access the API from the host machine by explicitly binding the web server to all interfaces, e.g. python manage.py runserver 0.0.0.0:8000. This should make the API browseable at http://dev.example.com:8000/api/v3/

Authentication¶

We currently enable Basic HTTP Authentication on the REST API. This can be temporarily disabled by commenting out the DEFAULT_PERMISSION_CLASSES line in the REST_FRAMEWORK section in app/pulp/app/settings.py. Note that this doesn't disable authentication, it just authorizes unauthenticated users to take any action. Basic Authentication should still work.

Starting Tasks¶

Currently the systemd service files are not copied over on the Pulp3 Vagrant environment, so celerybeat, resource manager, and workers have to be started manually.

sudo -u apache /usr/bin/celery beat --app=pulp.tasking.celery_app:celery --scheduler=pulp.tasking.services.scheduler.Scheduler -l=INFO --pidfile=/var/run/pulp/scheduler.pid

sudo -u apache /usr/bin/celery worker -A pulp.tasking.celery_app:celery -n resource_manager@%%h\
            -Q resource_manager -c 1 --events --umask 18 --pidfile=/var/run/pulp/resource_manager.pid\
            --heartbeat-interval=5 -l=INFO

sudo -u apache /usr/bin/celery worker -n reserved_resource_worker-123s@h\
          -A pulp.tasking.celery_app:celery -c 1 --events --umask 18\
          --pidfile=/var/run/pulp/reserved_resource_worker-123s.pid\
          --heartbeat-interval=5 -l=INFO

apply_async and apply_async_with_reservation tasks can be tested from a django shell python manage.py shell_plus I usually do the following to test tasks

from pulp.app.tasks import repository
from pulp.app.models import Repository
import uuid
repo_uuid=str(uuid.uuid4())
repo=Repository(name=repo_uuid)
repo.save()

repository.delete.apply_async(kwargs={'repo_name':repo_uuid})
repository.delete.apply_async_with_reservation("foo","bar",kwargs={'repo_name':repo_uuid})