Heh, that's almost exactly what I'm working on now. After looking at OpenStack and other solutions, I rolled my own.
My solution is cloud agnostic, and does have (almost-there!) multi-node support, and was built to support a local cloud provider (via Linux Containers) .. so you don't have to be online, pay an external provider, or pay the latency cost if you want to run stuff .. you can just do it locally.
This is LOADS more complex than it may seem: due to dynamic virtual network infrastructure, configuration dependencies on network locality, resource requirements, portability concerns, security concerns, etc.
Running OpenStack locally on your linux machine and interacting with it via an API may help with some of the networking complexities you're running into.
Is your project open source? I'd be interested to chat about how you're approaching the multi-node support in your stuff.
Please shoot me an email or send a tweet: jake@markupisart.com / @jakedahn on twitter
Looked at OpenStack locally but decided against it, can't remember precisely why but probably something to do with not wanting to use paravirtualization. Project is not open source but might be in future ... no time. Sent you an email.
You both should take a look at Salt Cloud. Since you are already working with Python Jake it may be worth looking into. The project is doing a lot of the same things and it has the advantage of bootstrapping with Salt.
If you build a few map files using salt-cloud, you have a quick vagrant-ish setup that you can start/stop/destroy with ease. Super easy to have a whole test cluster boot up for quick test/dev work. Fyi, salt is really awesome for people looking for alternatives to chef/puppet: http://saltstack.org
I am personally less than enthusiastic when it comes to puppet-style solutions for their tendency to create configuration drift; running the same command in more than one place expecting the same results is in my view rarely the best solution in terms of maintainability and reliability.
My solution is cloud agnostic, and does have (almost-there!) multi-node support, and was built to support a local cloud provider (via Linux Containers) .. so you don't have to be online, pay an external provider, or pay the latency cost if you want to run stuff .. you can just do it locally.
This is LOADS more complex than it may seem: due to dynamic virtual network infrastructure, configuration dependencies on network locality, resource requirements, portability concerns, security concerns, etc.
Our primary non-local cloud provider is EC2.