Pulp

As a developer, it's currently possible to set up a Pulp 3 development environment on a Vagrant VM, using the pulp/devel repository (branch 3.0-dev). That repository contains a vagrant file (Vagrantfile.example) and Ansible playbook (pulp-from-source.yml) that work hand-in-hand to set up a Vagrant VM.

This is a great state of affairs until you decide to set up a development environment on a non-Vagrant host. There's any number of justifications for wanting to do this. Here's an idiosyncratic list:

• For many people, learning how a virtualisation solution works is a necessary roadblock that stands them and productive work. If someone has become comfortable with RHEV, AWS, Linode, libvirt, beaker, or so on, what's the benefit in forcing them to re-visit a solved problem? I don't see any benefit, and I think that doing so may turn away potential contributors.
• In my experience, Vagrant is extremely troublesome to work with. I've encountered segfaults while executing vagrant up, errors installing vagrant-libvirt, fishy cleanup logic, and more.
• It will be easier for QE to troubleshoot certain issues if we can create Pulp installations with up-to-date code, as opposed to what's on PyPI. (The ability to perform a non-development from-source install would also be useful, but that's a separate conversation.)

How might this task be accomplished? At a high level, it's straightforward:

1. Run pulp-from-source.yml against a host.
2. Fix whatever errors are encountered.
3. Repeat as necessary.

So far, I've encountered an issue while executing the following task:

- name: check for pulp git repo
  include_role:
    name: common
    tasks_from: require_repo
  vars:
repo: pulp

This task fails with the following message:

The pulp git repo is not in /home/vagrant/devel. Either clone the repo or disable the corresponding role in the playbook.

The issue is that the existing Ansible dev installer assumes that the developer has code checked out on their bare-metal host, and that that code is mounted into the (Vagrant) VM. One good solution to this problem is to let the Ansible installer check for the presence of required git repositories. If they're absent, the installer can clone them. If they're present, the installer can leave them alone, so as to avoid disturbing the work a developer might be doing.

There are undoubtedly more issues that lie undiscovered. Such is coding.