utility infielding

I’ve been hard, hard at work on the Lustre Management Tools again for the last few weeks, and it’s really been a pretty interesting experience. More than most of my other software work, these tools really do cover a pretty tremendous range of software domains, and it’s been a lot of fun pulling them all together. The basic job of these tools is to provide a convenient, largely web-based interface through which an administrator or fifty can monitor, manage and (lightly) configure their Lustre storage system. In order to do that well, I need to touch a lot of different types of code. In descending pseudo-order of proximity to the user, we have:

  • DHTML and its devil-kin: you can do a lot of pretty cool stuff with HTML and JavaScript and CSS these days, though it’s still not a trivial process to make things work quite the way one wants on all the browsers one cares about, in the face of all the lovely asynchronous elements that make up the interweb. Certainly, we’ve come a long way since the days of NGR and my other early-career web apps, but it still took some clever (IMO) thinking to make sure that the HTML portions of the UI were relatively self-contained, while getting data in a reasonable fashion from…
  • HTTP-driven services: …the core monitoring service, which uses the minimal-but-eminently-serviceable “Python @BaseHTTPServer@”:http://www.xml.com/pub/a/2004/01/21/udell.html capabilities to implement a tiny, self-contained web server. This represents a huge step forward from my original plans (@modperl@ or @modpython@, with some Apache config-stanza or, worse, a pre-configured Apache package) in that installation is genuinely trivial, and it’s much easier to manage the application state. In addition to the web service, my trusty little master daemon leads a second life as
  • UDP-based collector: which, again, was quite easy to wire up, with the “@SocketServer.UDPServer@”:http://epydoc.sourceforge.net/stdlib/public/SocketServer.UDPServer-class.html bits just lying there begging for me to make use of them. I run a very simple single-threaded poll loop right now, handling either requests for web content (static UI scaffolding or generated-data) or status report packets send from my herd of
  • Featherweight monitoring daemons: In order to get data in a timely and efficient fashion from the collection of servers that provide Lustre storage, I whipped up a tiny little nanodaemon that listens on a well-known port for the collector’s registration message, and then blips out updates about its Lustre services every few seconds, so that we can have an up-to-date view of available space, server throughput, etc. In order to keep this part as lightweight as possible — it’s about 250 lines now, will likely be around 600 when I’m done — I wrote it in good old “C99″:http://www.kuro5hin.org/story/2001/2/23/194544/139, and hated every minute of it. Having to manually deal with memory allocation and string tokenization and whatnot is a huge drag on productivity, and I find myself wondering if it might not have been more productive in the medium-term to have done it in Python and then ported it to C if and when someone complained tthat it was too big or whatever. We already require Python for
  • ([User-space Lustre utilities]: A small handful of somewhat, er, organic tools exist for producing the current generation of Lustre config files, and acting on them to insert modules, configure them with the many and wondered and type-unsafe powers of @ioctl@, dance with the routing tables in the pale moonlight, format underlying filesystems, reverse the process for shutdown, you get the idea. I’ve been poking at these in various ways to expose some (IMO) nicer configuration syntax and reporting, though it’s not clear how much of that work will make it into the first release of these management tools. I’m of the opinion that these tools could, pretty much to a man, stand to be taken behind the woodshed for a few hours, but there are more important fish to fry right now.)
  • Lustre kernel-service data export: some of the data we want to expose, especially as regards the “holistic” Lustre status monitoring elements, are helpfully tracked within Lustre itself, but are not readily accessible to the user-space world in which my collector daemon lives. I’ve been collecting a small list of things that I want to export, either at all or just in a more manageable way, and I’ll probably start poking at that stuff next week. I may have to dive in a little deeper and collect some additional status factoids that we don’t currently track, but I’m hoping not before the first, impending release. Certainly, there’s a lot of interesting visualization and control that we can expose with resorting to that.

Along the way, I’ve also discovered that for OO programming, Python is much more pleasant to work with than Perl. Perl 5 was obviously encumbered by the basics of Perl 4, but dealing with all the @ISA and @Exporter@ and module-packaging nonsense was just way too hairy for me to want to deal with, to say nothing of the lack of robust exceptions. The killer tile was this passage from the “@perlsub@ man page”:http://www.perldoc.com/perl5.8.0/pod/perlsub.html#Prototypes:

Method calls are not influenced by prototypes either, because the function to be called is indeterminate at compile time, since the exact code called depends on inheritance.

Now, I’ve spent a lot of time working on and with dynamic languages, so I understand the problem their facing, but still: when two of the language’s most significant “programming in-the-large” features — support for object-orientation and some, any argument checking — are fundamentally incompatible, I find myself sliding the hammer back into the toolbox and looking at my collection of screws in a new light.

There were a handful of other niceties in Python, not the least of which is the handy ["REPL":http://www.gigamonkeys.com/book/lather-rinse-repeat-a-tour-of-the-repl.html]-esque interactive interpreter, complete with type-diving online help.

(I don’t hate Perl, you don’t have to bring your language wars to the comments for this post, etc.)

Comments are closed.