Norman Richards

When doing dev work on EC2, I find myself destroying and creating new EC2 instances many times in a day, and I find myself hitting the "Host key verification failed" message from SSH a bit.

You could turn off the check with -o "StrictHostKeyChecking no" on the command line or in your ~/.ssh/config file, but the warning ssh gives is a good one and not one you really want to turn off.  My approach has been to edit the ~/.ssh/known_hosts file and remove the old key.  SSH is nice enough to tell you the exact line number.  It's inelegant, but it's what I've done for years.

What I didn't realize is that ssh has a better solution.

ssh-keygen -R will update the known_hosts file, removing the old key.  The next connection will prompt you to verify and add the new key.  Much nicer.

I attended a recent AustinJUG on OSGi.  I think OSGi is one of those technologies that is hard to really grasp and have a solid opinion of until you've used it.  I spent most of last year developing a set of applications on OSGi and learning the ins and outs of OSGi while tech editing OSGi in Action, so many people came to ask my thoughts.  I am most certainly not an expert, but I have used it enough to have opinions.  I thought I'd summarize here:

OSGi does a really good job of what it does.  It does work.  You can break up your app into very independent modular components and manage them.  It's not a half-baked solution, and given the complexities of this kind of class loading, that says a lot.  There are still gotcha's with things like the context class loader. (OSGi ignores it)

OSGi is a very good fit for servers and services.  If you truly have lots of mostly-independent, dynamic services that need to work together, you will like what OSGi gives you.  It can be used  for webapps, but it is not a great fit.  After working with it, the developers I was working with wanted to move the web server and WAR files out of the OSGi environment.

OSGi does not feel like modern Java.  OSGi was designed before the Java 5 revolution.  The APIs are cumbersome and feel outdated.

You will want to use a some sort of framework with it.   We used the Spring OSGi integration.  I didn't enjoy that, but it seems like the best choice when keeping in mind the big picture.

Working with your own code is wonderful.  Working with other people's code is not so easy.  If someone isn't managing an OSGi bundle for the libraries you want to use, you will feel pain.  Even if they are, you may still have headaches.

Summary: OSGi works, but don't use it unless you really need it.

Working mostly in Python at the day job has been an interesting experience.  For them most part integrating the new language and libraries has been fairly straightforward.  The dynamic nature leads to efficiencies on one end, but it also introduces a whole host of annoyances.  I spend a lot more time tracking down subtle errors that would have been immediately obvious in Java, for example.   

Of all the things I've encountered so far, the thing that's caused me the most headache has been a dumb monkey patch made by the M2Crypto library.  M2Crypto is a replacement SSL library required by own of our tools.  It apparently provides some functionality not in the standard python SSL code.  That's fine, except that in order to provide it's functionality, M2Crypto does this brilliant patch of urllib:

This apparently works for most urllib use, the the urllib.urlretrieve, which we were using, fails when retrieving https URLs.  It was a bear to track down, but once I realized that the function worked fine in a bare python and failed in the virtualenv python with all our third party libraries, it just took some time single-stepping through in the debugger to figure out where the two environments differed.

Since the open_https method is completely destroyed my the patch, the only option was to switch to urllib2.  However, since urllib2 doesn't seem to have kept the urlretrieve function around, I had to rewrite the urlretrieve functionality on top of it.  

This is exactly the kind of thing I was most afraid of when it came to working with Python - having to deal with other developers who decided it would be great to change the way base system libraries work.  Looking at the big picture, it was really only a minor annoyance - a few lost hours at most.  The real harm is in the feeling of instability it brings.  I want to know exactly what the system is doing and why, and it's hard to do when one library decides to muck around with another libraries internals.

I wanted to have a UUID primary field in a django model.  It isn't hard to create a CharField with a value that defaults to a UUID.   The django_extensions has a UUIDField is a nice all in one solution.  It works well as a primary key, except for a messy case with InlineModelAdmin which only allows non-editable primary keys if they are an AutoField.   

The workaround I found, after digging through the code a bit was to mimic the behavior of AutoField to trick InlineModelAdmin into doing the right thing.  I extended UUIDField like this:

After a bit more searching, I later found this was a known bug.  More interestingly, one of the commenters on the bug had considered the same solution and rejected it.  Take a look at the bug report for his reasoning, but the error condition he points out only occurs when the default value is None.  If the field has a default value, as is the case with this CharField-extended model, the potentially problematic logic doesn't kick in.  I haven't battle-tested the solution yet, but initial testing looks like it performs correctly. 

I've been struggling for a while to get a handle on OpenStack.  Since Rackspace, the company that initially pushed the idea, is based nearby, there's been quite a lot of noise about OpenStack locally.  I've attended several talks on OpenStack, but unfortunately I still haven't really gotten the big picture.

As a developer, my first question is why I should care open OpenStack.  I'm intrigued, for sure, and my background should leave no doubt that I'm a huge open source proponent.  However, I don't ever expect to run my own cloud.  As a developer, if I run on Amazon EC2, I see a set of Linux boxes (open source) and a public API I can use to manage my instances.   Whether the cloud infrastructure is open source or not, doesn't seem to matter much.  I should be able to spin up a Linux box on the Rackspace cloud just as easily and have nearly the same view of the world.  

The management of instances seems to be the key difference.  Services like Rightscale go a long way to bridging the gaps between the different cloud offerings, but I can certainly see how this would all be easier if the various cloud services had a common management API.  Unfortunately, I don't see much talk about management APIs from OpenStack.  Maybe I've missed it, or maybe it's just too early.  It's not really clear. What exactly is the OpenStack view of management APIs?

More important than the infrastructure APIs is the platform service APIs.  I'm a huge fan of S3 and SQS, for example, both of which are big reasons I go with EC2.  Though technically both are quite accessible outside of EC2, I would only seriously consider moving if equivalent services were available, preferably ones with standard APIs that would give me true cloud service portability.  OpenStack has the start of this with Swift, their version of S3.  However, I'm still a little unclear on the big picture.  Will OpenStack create a core platform of AWS-like cloud services based around standard APIs?  Or, is the goal to create a linux-like environment for the creation of (hopefully compatible) platform packages that can be installed into an OpenStack cloud ad hoc?  It seems to me like the later is closer to the approach, and although that's quite an interesting possibility, I'm not sure how OpenStack then will lead to a simpler, more standardized cloud than we have now.

I'm not down on OpenStack.  I just don't really understand the project.   As an app developer, I'm clearly not the primary audience of OpenStack, yet.  However, cloud platforms exist to serve the developers, and if you are designing an open platform from the ground up, I would hope to have been able to get a little bit better of a perspective on what the world of an OpenStack cloud will look like to a developer.