Devstack allows the developer to work with the master branches for upstream OpenStack development. But Devstack performs many operations (such as replacing pip) that might be viewed as corrupting a machine, and should not be done on your development workstation. I’m currently developing with Devstack on a Virtual Machine running on my system. Here is my setup:
Both my virtual machine and my Base OS are Fedora 20. To run a virtual machine, I use KVM and virt-manager. My VM is fairly beefy, with 2 GB of Ram allocated, and a 28 GB hard disk.
I keep my code in git repositories on my host laptop. To make the code available to the virtual machine, I export them via NFS, and mount them on the host VM in /opt/stack, owned by the ayoung user, which mirrors the setup on the base system.
Make sure NFS is running with:
sudo systemctl enable nfs-server.service sudo systemctl start nfs-server.service
And to enable changes in this file
Make sure firewalld has the port for nfs open, but only for the internal network. For me, this is interface
virbr0: flags=4163 UP,BROADCAST,RUNNING,MULTICAST mtu 1500 inet 192.168.122.1 netmask 255.255.255.0 broadcast 192.168.122.255
I used the firewall-config application to modify firewalld:
For both, make sure the Configuration select box is set on Permanent or you will be making this change each time you reboot.
First add the interface:
And enable NFS:
In the Virtual machine, I added a user (ayoung) with the same numeric userid and group id from my base laptop. To find these values:
$ getent passwd ayoung ayoung:x:14370:14370:Adam Young:/home/ayoung:/bin/bash
I admit I created them when I installed the VM, which I did using the Anaconda installer and a DVD net-install image. However, the same thing can be done using user-add. I also added the user to the wheel group, which simplifies sudo.
On the remote machine, I created /opt/stack and let the ayoung user own them:
$ sudo mkdir /opt/stack ; sudo chown ayoung:ayoung /opt/stack
To mount the directory via nfs, I made an /etc/fstab entry:
192.168.122.1:/opt/stack /opt/stack nfs4 defaults 0 0
And now I can mount the directory with:
$ sudo mount /opt/stack
I went through and updated the git repos in /opt/stack using a simple shell script.
for DIR in `ls` ; do pushd $DIR ; git fetch ; git rebase origin/master ; popd ; done
The alternative is setting RECLONE=yes in /opt/stack/devstack/localrc.
When running devstack, I had to make sure that the directory /opt/stack/data was created on the host machine. Devstack attempted to create it, but got an error induced by nfs.
Why did I go this route? I need to work on code running in HTTPD, namely Horizon and Keystone. THat preclueded me from doing all of my work in a venv on my laptop. The NFS mount gives me a few things:
- I keep my Git repo intact on my laptop. This includes the Private key to access Gerrit
- I can edit using PyCharm on my Laptop.
- I am sure that the code on my laptop and in my virtual machine is identical.
This last point is essential for remote debugging. I just go this to work for Keystone, and have submitted a patch that enables it for Keystone. I’ll be working up something comparable for Horizon here shortly.