{"id":1662,"date":"2016-01-20T20:42:39","date_gmt":"2016-01-21T01:42:39","guid":{"rendered":"http:\/\/unitstep.net\/?p=1662"},"modified":"2016-01-29T18:37:30","modified_gmt":"2016-01-29T23:37:30","slug":"remote-python-debugging-using-pydevliclipse-for-openstack-swift","status":"publish","type":"post","link":"https:\/\/unitstep.net\/blog\/2016\/01\/20\/remote-python-debugging-using-pydevliclipse-for-openstack-swift\/","title":{"rendered":"Remote Python debugging using PyDev\/LiClipse for OpenStack Swift"},"content":{"rendered":"

We all know what debugging is – stepping through running code, line by line, inspecting variables and trying to figure out what’s wrong with your program while simultaneously tearing your hair out. However, usually when debugging Python code, the Python process is running locally on your system. What happens if you want to debug through code running on another server?<\/p>\n

This is typically the case when working with OpenStack Swift, since the Swift-all-in-one (SAIO) instructions<\/a> tell you to use a VM to run your Swift installation in, and a Vagrant VM provided by SwiftStack<\/a> simplifies this. However, this means that the Swift code is not running locally; it’s running inside of your VM – so how do you debug into it?<\/p>\n

Remote debugging aims to solve this by allowing you to inspect, trace and step through code running in a Python process on another machine. Setting this up requires some work, but is well worth the effort when debugging a non-trivial application running on a remote server or VM.<\/p>\n

<\/p>\n

Purpose<\/h2>\n

This guide will help you get remote debugging working using PyDev<\/a> and the LiClipse Python IDE<\/a>. (If you are using PyCharm<\/a>, it also supports remote debugging, and also uses PyDev<\/a>, but I haven’t personally used it – but the instructions are likely to be similar)<\/p>\n

For those of you from a Java background (like myself), remote debugging into a JVM is almost second nature, as usually you’re working with application servers\/containers that run in a separate VM. In the case of Java, the typical remote debugging workflow had your IDE as the debugging client, and it connected to the remote “debug server”, which ran in the same JVM as the target code, and was enabled using the JVM debug options.<\/p>\n

For remote debugging in Python using PyDev, the roles of client\/server are somewhat reversed. For PyDev remote debugging<\/a>, the debug server runs locally and is started by your IDE, and the remote Python process that you wish to debug acts as a client to connect to it. This means the target code that you want to debug must be modified so that it connects to your debug server.<\/p>\n

Here’s a conceptual diagram of how Python remote debugging works:<\/p>\n

\"python-remote-debug-concept\"<\/p>\n

Getting Started with LiClipse<\/h2>\n

I’ll be using LiClipse, a version of Eclipse that comes with PyDev pre-installed for this tutorial. I realize that Eclipse and other “heavy” IDEs aren’t that popular for Python development, however I’ve found LiClipse (via the PyDev plugin) to be quite useful for Python work. If you already know how to use Eclipse\/LiClipse, you can skip this section.<\/p>\n

You can install PyDev as an Eclipse Plugin<\/a>, or just install LiClipse<\/a>, which gives you everything. I recommend the latter. If you are using Homebrew Cask, it’s as simple as running:<\/p>\n

$ brew cask install liclipse<\/code><\/pre>\n
Note that you will need to have at least Java 7 installed since LiClipse is based on Eclipse, and Eclipse requires a JVM to run.<\/p>\n
Once LiClipse is installed, open it, and when prompted, select a workspace location. (You probably don’t want to use the default of \/Users\/fabioz\/Documents\/LiClipse Workspace<\/code>)<\/p>\n
The workspace location is where LiClipse will store metadata related to preferences, projects, which files you have open, etc. I typically use something like ~\/development\/LiClipse Workspace<\/code><\/p>\n
Once LiClipse is open, you’ll want to ensure the debug controls are always visible. This isn’t necessary but it makes things easier:<\/p>\n
– Right-click Python icon in upper right corner -> Customize View<\/p>\n
\n\"liclipse-customize-perspective\"<\/a>\n<\/p>\n
– Action Set Availability: Ensure all “PyDev*” entries are checked.<\/p>\n
\n\"liclipse-action-set\"<\/a>\n<\/p>\n
– Tool Bar Visibility: Ensure all of “PyDev Debug” is checked.<\/p>\n
\n\"liclipse-toolbar-visibility\"<\/a>\n<\/p>\n
When asked for a Python interpreter, clicking auto-config should work. If it doesn’t, then will have to point to your Python installation, i.e. where your Python binaries are.<\/p>\n
You’ll then want to import the Swift project\/codebase into LiClipse. This can be done by importing it as a Git project, like so:<\/p>\n
– PyDev Package Explorer: Right-click anywhere -> Import -> Git -> Next
\n– Projects from Git -> Existing Local Repository -> Next
\n– Add -> (Browse to your Swift git checkout folder) -> Check the Swift folder in the Search results -> Finish, Next
\n– Import as General Project -> Next -> Finish<\/p>\n
You should then see the Swift git checkout in the PyDev Package Explorer Window.<\/p>\n
Configuring Remote Debugging in PyDev\/LiClipse<\/h2>\n
Now that you have PyDev\/LiClipse setup, you can start remote debugging. As mentioned before, Python Remote Debugging works like this:<\/p>\n
1. The Debug Server runs locally, i.e. on your developer machine.
\n2. The code you are remotely debugging must connect to this debug server.
\n3. After that, you are able to debug, trace and inspect code running remotely.<\/p>\n
Because your local machine acts as the debug server, you must know its IP address so you can connect to it in step (2). If the remote code is running on a physically different server than your local machine, then you just need to know your local machine’s IP address.<\/p>\n
However, if you are running a VM, as is recommended in the Swift-All-In-One instructions<\/a> (and provided by the Vagrant SAIO<\/a>), then it’s bit more complicated. In this case, the “remote” server is a VM running on your local\/host machine. In this case, you should use the IP assigned to your local\/host machine from the Virtual Machine Provider’s adapter. This is a virtual adapter that acts as a sort of bridge between your host machine and the virtual machine.<\/p>\n
You can use your local machine’s “regular” IP address, but it might change (due to DHCP), while the virtual adapter IP address should not.<\/p>\n
For example, if using VirtualBox, you can discover the host machine’s IP address by using ifconfig<\/code> in OS X\/Linux, or ipconfig<\/code> in Windows. For OS X\/Linux, look for the network adapter named “vboxnet*”:<\/p>\n
$ ifconfig | grep -A 5 vboxnet\r\nvboxnet0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500\r\nether 00:00:00:00:00:00 \r\ninet 192.168.8.1 netmask 0xffffff00 broadcast 192.168.8.255<\/code><\/pre>\n
In Windows, the network adapter name will have “VirtualBox” in it:<\/p>\n
>ipconfig\r\n...\r\nEthernet adapter VirtualBox Host-Only Network:\r\n\r\n  Connection-specific DNS Suffix  . :\r\n  Link-local IPv6 Address . . . . . : ***************************\r\n  IPv4 Address. . . . . . . . . . . : 192.168.8.1\r\n  Subnet Mask . . . . . . . . . . . : 255.255.255.0\r\n  Default Gateway . . . . . . . . . :<\/code><\/pre>\n
In both examples above, the local\/host machine IP is 192.168.8.1. Yours may be different. Remember this IP address, as you will use it to connect from the remote Python process to the debug server on your local machine.<\/p>\n
Now you’ll need to start the PyDev debug server in LiClipse\/Eclipse:<\/p>\n
1. PyDev Menu -> Start Debug Server
\n2. Allow access through local Firewall if prompted.
\n3. The Console should pop up at bottom and show: “Debug Server at port: 5678”
\nThis is the default port; you can change it in LiClipse Preferences.
\n4. Allow network access if prompted by OS\/security settings.<\/p>\n
You can also (optionally) switch to the Debug Perspective in LiClipse:<\/p>\n
– Window -> Open Perspective -> Other -> Debug
\n– You can switch back to normal Python view using the buttons in the upper right corner.
\n– Here you can see the call stack, variables and their values and other state of the running program.<\/p>\n
Next, you’ll need to copy over the PyDev debug source code to your VM. It’s needed so that a connection can be made to the debug server running on your local machine. The PyDev debug source is located within your LiClipse installation at a location like this:<\/p>\n
{path to LiClipse}\/liclipse\/{liclipse version number}\/liclipse\/plugins\/org.python.pydev_{pydev version number}\/pysrc<\/code><\/pre>\n
For example:<\/p>\n
\/opt\/homebrew-cask\/Caskroom\/liclipse\/2.1.0\/liclipse\/plugins\/org.python.pydev_4.1.1.201505312114\/pysrc (OS X example)\r\nC:\\LiClipse 2.4.0\\plugins\\org.python.pydev_4.4.0.201510052047\\pysrc (Windows example)<\/code><\/pre>\n
Copy over this entire folder (pysrc<\/code>) to the VM. The easiest way to copy this over to your VM is by using the VM’s shared folder. Assuming your shared folder is at: ~\/development\/openstack\/vagrant-swift-all-in-one\/<\/code><\/p>\n
$ cp -r \/opt\/homebrew-cask\/Caskroom\/liclipse\/2.1.0\/liclipse\/plugins\/org.python.pydev_4.1.1.201505312114\/pysrc\/ ~\/development\/openstack\/vagrant-swift-all-in-one\/pydev<\/code><\/pre>\n
This copies the pysrc<\/code> folder over to a folder named pydev<\/code> on the VM.<\/p>\n
SSH into your VM, and make sure the pysrc<\/code> folder shows up. For me, the shared folder is mapped to \/vagrant<\/code>, so I see it at \/vagrant\/pydev<\/code><\/p>\n
In order to make this accessible to Python on the VM, you need to add it to your $PYTHONPATH<\/code> environment variable. While SSH’d into the VM, add it to the $PYTHONPATH<\/code> using a command like this: (Assuming the PyDev source you copied over is at \/vagrant\/pydev<\/code> on the VM)<\/p>\n
$ export PYTHONPATH=\"$PYTHONPATH:\/vagrant\/pydev\"<\/code><\/pre>\n
Hello, Remote Python Debugging<\/h2>\n
Before diving into Swift code and debugging it, let’s debug a simple Python script running remotely on our VM to make sure everything works. Make sure the debug server is running on your local machine (you should see “Debug Server at port: 5678” in the LiClipse console)<\/p>\n
Create a script at ~\/test-script.py<\/code> with the following contents, but replace <YOUR LOCAL MACHINE IP HERE><\/code> with the IP you found above. In my case, it was 192.168.8.1. Try the VirtualBox VM IP address first; if it doesn’t work, then use your local machine’s “regular” IP address.<\/p>\n
#!\/usr\/bin\/env python \r\n\r\nimport pydevd\r\npydevd.settrace('<YOUR LOCAL MACHINE IP HERE>', port=5678)\r\n\r\na = 1\r\nb = 2\r\nc = a + b\r\n\r\ns = 'hello world'\r\nprint s<\/code><\/pre>\n
The first two lines are the how the debug breakpoint is set. Note that this means the code you want to debug must be modified by adding these two lines! These two lines basically connect to the remote debug server (running on your local machine) and allow control through the LiClipse user interface. Note that this is very much different from Java remote debugging, where you don’t need to modify the target code.<\/p>\n
Now, make the script executable:<\/p>\n
$ chmod u+x test-script.py<\/code><\/pre>\n
And run it:<\/p>\n
$ .\/test-script.py<\/code><\/pre>\n
After running this, you should see the Debug Server show the thread and script in the Debug view. You can now step through the code and inspect the variables. The buttons at the top of the screen are for Step Into (F5), Step Over (F6) and Step return (F7). If you’re familar with debugging, these should make sense.<\/p>\n
\n\"debug-sample-session\"<\/a><\/p>\n
The Variables view shows the state\/value of the variables currently defined. You can step through some lines of code (F6) and see how the values change. You can even modify a value while the code is stopped. (Note that the values shown in the Variables view show the type as well, like str: hello world<\/code>, but when you edit a variable, you should just use the literal value, i.e. 'hello world'<\/code>)<\/p>\n
You can click the Resume\/F8 button at any time to return control to the program, and it will execute normally.<\/p>\n
Remote Debugging Swift Code<\/h2>\n
Now that you’ve debugged a simple Python script remotely, let’s move onto the Swift code. Unfortunately, there is another change we need to make to Swift code before we can debug into the code. The PyDev debugging does not play well with green threading, so we’ll need to temporarily disable that in order to get debugging to work<\/a>. This is obviously not an optimal solution, but I have not yet found a better way around this.<\/p>\n
Open up swift\/common\/wsgi.py<\/code> and find the line like this: (It should be around line 411<\/a>)<\/p>\n
eventlet.patcher.monkey_patch(all=False, socket=True, thread=True)<\/code><\/pre>\n
Change the line to this:<\/p>\n
# TODO: Disabling eventlet green threading to allow for PyDev debugging to work.\r\n#eventlet.patcher.monkey_patch(all=False, socket=True, thread=True)\r\neventlet.patcher.monkey_patch(all=False, socket=True, thread=False)<\/code><\/pre>\n
This disables green threading. If you don’t do this, the remote debugging will not work properly.<\/p>\n
I’ll debug a sample functional test. Open up swift\/common\/middleware\/slo.py<\/code> and browse to StaticLargeObject.__call__()<\/code> and add in a breakpoint here right at the beginning of the method:<\/p>\n
def __call__(self, env, start_response):\r\n\r\n    import pydevd\r\n    pydevd.settrace('<YOUR LOCAL MACHINE IP HERE>', port=5678)\r\n\r\n    \"\"\"\r\n    WSGI entry point\r\n    \"\"\"\r\n    ...<\/code><\/pre>\n
Restart Swift for the changes to take effect:<\/p>\n
$ swift-init main restart<\/code><\/pre>\n
Now, change directory to swift\/test\/functional<\/code> and run a simple functional test that hits the SLO code:<\/p>\n
$ nosetests --exe -s tests.py:TestSlo.test_slo_get_simple_manifest<\/code><\/pre>\n
You should see Debug Server show the call\/stack trace in the Debug view, as well as the line in StaticLargeObject.__call__()<\/code> highlighted where the remote breakpoint was hit. You will have to hit “Resume”\/F8 a whole bunch of times to get through the test, since this method is invoked many times because it’s in the request pipeline.<\/p>\n
Unfortunately, if you disconnect the debug server before resuming, Swift may hang and you’ll have to run swift-init main restart<\/code> to get things back to normal. Because of this, you’ll want to set breakpoints to very specific areas of code so you don’t have to resume too many times like in the example above. I have not yet found a way to set conditional breakpoints, i.e. breakpoints that only fire when a variable has a certain value, but being able to do this would help.<\/p>\n
Conclusion<\/h2>\n
Remote debugging in Python is a little more involved, but well worth the effort as it can offer much more insight into why something bad is happening, versus the alternative of just putting a bunch of logging statements everywhere. Please leave a comment below if you have any suggestions for improvements. Thanks for reading!<\/p>\n
References<\/h3>\n
    \n
  1. http:\/\/www.pydev.org\/manual_adv_remote_debugger.html<\/a><\/li>\n
  2. http:\/\/www.liclipse.com\/<\/a><\/li>\n
  3. https:\/\/www.jetbrains.com\/pycharm\/help\/remote-debugging.html<\/a><\/li>\n
  4. http:\/\/stackoverflow.com\/questions\/6989965\/how-do-i-start-up-remote-debugging-with-pycharm<\/a><\/li>\n
  5. http:\/\/docs.openstack.org\/developer\/swift\/development_saio.html<\/a><\/li>\n
  6. https:\/\/github.com\/swiftstack\/vagrant-swift-all-in-one<\/a><\/li>\n
  7. http:\/\/www.pydev.org\/download.html<\/a><\/li>\n
  8. http:\/\/www.liclipse.com\/download.html<\/a><\/li>\n
  9. https:\/\/github.com\/caskroom\/homebrew-cask\/blob\/master\/Casks\/liclipse.rb<\/a><\/li>\n
  10. http:\/\/ilearnstack.com\/2013\/05\/30\/debug-openstack-code-local-remote-with-eclipse-and-pydev-plug-in\/<\/a><\/li>\n
  11. https:\/\/ask.openstack.org\/en\/question\/2997\/debugging-openstack-swift-with-eclipse-and-pydev\/<\/a><\/li>\n
  12. https:\/\/github.com\/openstack\/swift\/blob\/master\/swift\/common\/wsgi.py#L411<\/a><\/li>\n<\/ol>","protected":false},"excerpt":{"rendered":"
    We all know what debugging is – stepping through running code, line by line, inspecting variables and trying to figure out what’s wrong with your program while simultaneously tearing your hair out. However, usually when debugging Python code, the Python process is running locally on your system. What happens if you want to debug through […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[318,403,277],"tags":[],"_links":{"self":[{"href":"https:\/\/unitstep.net\/wp-json\/wp\/v2\/posts\/1662"}],"collection":[{"href":"https:\/\/unitstep.net\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/unitstep.net\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/unitstep.net\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/unitstep.net\/wp-json\/wp\/v2\/comments?post=1662"}],"version-history":[{"count":39,"href":"https:\/\/unitstep.net\/wp-json\/wp\/v2\/posts\/1662\/revisions"}],"predecessor-version":[{"id":1725,"href":"https:\/\/unitstep.net\/wp-json\/wp\/v2\/posts\/1662\/revisions\/1725"}],"wp:attachment":[{"href":"https:\/\/unitstep.net\/wp-json\/wp\/v2\/media?parent=1662"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/unitstep.net\/wp-json\/wp\/v2\/categories?post=1662"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/unitstep.net\/wp-json\/wp\/v2\/tags?post=1662"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}