Pulp

Some roles may work for both Pulp 2 and Pulp 3. Others could be converted to do the parts that are common between the 2, and call other tasks for Pulp2/Pulp3. This would be nice, but it would increase the "backwards compatibility tax", so I think we should keep them completely separate. Pulp 2 will have a decreasing importance, and we don't want to waste resources maintaining our dev-setup to work for both.

+1 to keeping the roles totally separate.

One question I've been wondering about is how many pulp checkouts will there be. Say a "set of checkouts: consists of all the repos that back a single Vagrant environment, i.e. pulp, pulp_rpm, pulp_puppet, etc. I think if we have to have two sets of checkouts then the practical benefit goes down because if you have two sets of checkouts you can just checkout the devel folder twice also and you'll also have two Vagrantfiles.

I think the only issue there is that they both register the same libvirtd name, so maybe we should just change the libvirtdname insead?

If we did want to use just one set of checkouts I imagine you can switch your branches to master with checkout.py, run `vagrant up pulp2`, leave it on, switch to 3.0-dev with checkout.py, and run `vagrant up pulp3`. My only concern is that each Vagrant up needs to not disturb the NFS mount of the other machine so we would need to test this. If we did this, for each environment you leave you, you would just make sure to have the branches checked out correctly and then run `prestart` before you use it.

Given that is how this would be used, maybe just making the two libvirt names be pulp2_devel and pulp3_devel would be easier.

What do you think?

This will be a huge help. Thanks!

https://github.com/pulp/devel/pull/65
https://github.com/pulp/devel/pull/66

https://pulp.plan.io/projects/pulp/wiki/Developer_Install_Options