Python Databases Workshop, Post-Mortem
posted by brian at 09:20 PM
So apparently doing a workshop is orders of magnitude harder than doing a talk. I say this because the Making Databases Fun with Python workshop I hosted tonight went horribly awry due to technical failures.
First off, if you're looking for workshop notes, here's the file I used to guide myself through the worskhop. If you're looking for a screencast and audio, which I was all prepared for; sorry, I totally forgot to set up both of them. Anyway, they wouldn't have been very useful because everything went wrong.
First I'll explain the setup I used for the workshop, then I'll theorize about what went wrong. The computer lab I used was stocked with over 20 Windows machines. Since I didn't have privileges to install Python and all the necessary libraries, I simply ran PuTTY on all of them and connected to a FreeBSD server I had set up for this purpose.
Everyone used PuTTY to log onto the same account on the FreeBSD machine, which had this zsh login script:
python2.4 login.py
And login.py contained:
import os
import IPython
print """
Hi! Welcome to my talk, Making Databases Fun with Python.
This login process will get you set up with your own sandbox
folder and Python interpreter. No password is required.
"""
username = None
while not username:
username = raw_input("Enter your Case network username: ").strip().lower()
try:
os.mkdir(username)
except OSError:
print "Sandbox found."
else:
print "Sandbox created."
print "Entering sandbox..."
os.chdir(username)
print "Starting Python!"
while True:
IPython.Shell.start().mainloop()
Okay, this script doesn't account for any extreme cases going wrong, but it covers the basics and it worked fine. The person gives their unique ID, and it puts them in an IPython shell in their own directory.
The first thing that went wrong was after almost 20 people were logged in, SSH on the remote machine stopped accepting logins. The first thing that came to mind was that this was a FreeBSD security feature. Luckily, there was only one person left without an IPython shell from this happening.
Not soon after getting into the DBM example, people started having import problems. Despite everyone being connected to the same machine, running the same installation of Python, some people would get errors trying to import anydbm and some wouldn't. I got around this by just telling some people to import dbhash or gdbm instead, which worked fine.
Things really went haywire when we got to the DBAPI portion of the workshop. Everyone could import pysqlite2 okay, but most people started getting errors when trying to make a connection object. Some people got back a valid connection object, while others had an exception claiming to not be able to read the database file. Keep in mind, these people were all in their own sandbox working with their own database file. I figured it might be a thread-safety issue, but why would that be a problem if they're all using their own database?
The rest of the talk covering SQLAlchemy wasn't much better. People kept on getting import errors or just weird exceptions claiming to not be able to create or read the database file. It was a total disaster. Sometimes people encountered failures, then simply tried again later and it worked, which really sounds like a threading issue.
So, Python and FreeBSD folks, what do you think? Did SSH lock out my logins eventually, even though there were practically no failed login attempts? Was my FreeBSD using an unreasonably low file handle limit? Was having everyone import all these modules around the same time bumping up against the GIL? Or simply thread-safety issues in some modules? Keep in mind, there were about 20 people at the talk, just sitting mostly idle in an IPython shell. That's all it takes to fail at loading anydbm?
Besides the database file creation errors, at some point different exceptions were saying they couldn't find lib/libc or zlib. Also, while troubleshooting and reloading IPython, sometimes it just said 'IPython not found' and dumped me into a regular Python shell. But trying again loaded IPython just fine. Was this a result of having IPython running as the same user many times at once?
Was it my fault? Was it FreeBSD's fault? Was it Python's fault?
Comments
How about /var/log/messages entries?
Anything on the console output while people were trying to login? SSHd will normally complain, so will too many open file handles.
I don't think it's fair to say it was your fault at least....