OpenStack has many different code bases. Figuring out how to run in a debugger can be maddening, especially if you are trying to deal with Eventlet and threading issues. Adding HTTPD into the mix, as we did for Keystone, makes it even trickier. Here’s how I’ve been handling things using the remote pythong debugger (rpdb).
The maximum header size between a HTTPD and an WSGI process is fixed at 8 Kilobytes. With a sufficiently large catalog, the token in PKI format won’t fit. Compression seems like it would be such an easy solution. But the there is a Hobgoblin or two hiding in the shadows.
The SQL migration mechanism in Keystone is interesting enough to warrant some attention. If you need to modify the SQL database in any of the Open Stack projects, you are going to use a similar approach. Here is a step by step I have recorded of a SQL upgrade script I am writing for a feature in Keystone.
If you ever want to build and RPM, you need to make sure that the things it requires are installed. These are listed in the SPEC file on lines that begin with BuildRequires. Installing these by hand is time consuming enough that it should be automated. Here’s a first hack in Python.
#!/usr/bin/python import sys import re build_re = re.compile('BuildRequires:.*') compare_re = re.compile('.*=.*') def main(): if (len(sys.argv) > 1): spec = open(sys.argv) for line in spec: if build_re.match(line): for token in line.rsplit(" "): if build_re.match(token): continue if compare_re.match(token): break token = token.rstrip(" ,\n\r") if len(token) > 0: print token if __name__ == "__main__": main()
To use it, save in a file called buildreqs.py and run:
sudo yum install `./buidreqs.py ~/rpmbuild/SPECS/krb5.spec`
Object oriented design principals are not language specific. While there is variation from language to language on details of implementations, and some techniques are not appropariate to all languages, for the most part, good design is good design.
The next interim release of Openstack Keystone will once again have LDAP support. I am developing against OpenLDAP to start, as that is what the LDAP support has been based on in the past. However, the directory server that backs FreeIPA works perfectly well, and provides a backend that allows for Keystone support.
Kerberos doesn’t tell you who you are. Seems like a funny thing, but when you use Kerberos Auth on the web, the browser has not way of telling you “this is the principal that you are using.” For the UI in FreeIPA, I need to display just thins information. To find it, I have to look to the server to tell me.
Thus begins my study of FreeIPA plugins. I wrote a simple plugin, the whoami plugin, that did just what I needed. I returned the Principal in the summary, and all was good.
Now I need more. I need to know the role groups of which the current user is a member. This information is on the user object already. So, good-bye whoami plugin: we are going to add your behavior to the user plugin, where it belongs.
The key piece of information that made this work possible was how to get a breakpoint to stop the code and let me step through it. The trick, probably old hat to the Pythonistas out there, but new to me was this simple line:
import pdb; pdb.set_trace()
Without that, none of the breakpoints I’d set would get executed, maybe due to threading or something. Not sure, but with this, I was able to determine that what I needed to do was to modify the filter.
I ran the lite-server like this:
Which is actually preferable to running it like this
python -m pdb lite-server.py
As you don’t have to type cont, and the debugger is still activated by the breakpoints.