Sometimes I don’t want to do things “the hard way” – I just need a testing environment. Kubernetes is one of those things when I’m developing applications. So when I needed a development cluster for my newest app, I wanted something fast, easy and without a lot of dependencies. Luckily, the latest releases of Kubernetes has made great strides in reducing the time between wanting a Kubernetes cluster and actually using a Kubernetes cluster – If you are on a public cloud, not OpenStack.
Back in April, I gave a presentation in Portland at the OpenStack Summit on the architecture of OpenStack Grizzly. As the presentation was limited to 45 minutes, I said I would post a more in-depth article about it (similar to my last Folsom OpenStack Archtecture post) shortly. Unfortunately, work got in the way. I have finally made good on my promise and posted the full length article along with several clarifications over on my work blog at http://www.
As the Folsom release of OpenStack is due to be released this week, I’ve taken the time to update my “Intro to OpenStack Architecture 101” for the official documentation. It merged into the repos yesterday and below is an expanded version of it. OpenStack Components There are currently seven core components of OpenStack: Compute, Object Storage, Identity, Dashboard, Block Storage, Network and Image Service. Let’s look at each in turn:
While it is still seven weeks until OpenStack “Essex” (2012.1) officially is released, release candidates are just around the corner. With this in mind, I thought it would be a good chance to revisit my earlier blog post on OpenStack Compute (“Nova”) architecture. This time around, instead of detailing the architecture of just a single service, I’ll look at all the pieces of the OpenStack project working together. To level-set everyone’s understanding, let’s briefly review the OpenStack project components and history.
You may have noticed that I have not posted anything in the last two months. And as you have probably guessed, it was because I was busy working on something else. That “something else” was writing Deploying OpenStack for O’Reilly Media. The book is intended to provide an introduction to the OpenStack project (Glance, Swift and Nova) Cactus release, an architectural overview of each component and some best practices for their deployment.
I just got back from the OpenStack Developers Summit and while I am still trying to compile my thoughts on the event, I thought I’d dash off this little tidbit: A slight annoyance in administering (and troubleshooting) OpenStack Nova is identifying your installed version. This information is actually readily (i.e. programmatically) available within the code (and logged at the beginning of most logfiles), but we hadn’t exposed it to administrators on the command line until Nova trunk revision #1036.
NOTE: I’ve updated and expanded this blog post for the Folsom release. Click here to read the updated version. One of the common refrains I hear from people getting started with OpenStack is the lack of good introductory architectural overviews of the project. I was confronted by the same problem when I first started with the project - it was easy to get the low level code and API documentation but it was very difficult to find a “lay of the land”-type overview.
I have a long running blog that I struggle to keep current. The blog centers on mountain bike racing scene here in Northern California, so the content needs to stay timely as there are races every weekend all year long. Unfortunately, I don’t have a lot of free time to devote to it. Long story short, I wanted to automatically create a post every Thursday morning to let people know what races were being held that weekend.
Over the past three weeks, new Nova core developer Josh Kearney (congrats @jk0) and I have been working on adding runtime configuration of instance types (read the full specification) to the OpenStack Nova compute service. Instance types (or “flavors” as Rackspace calls them) are resources granted to virtual machines (“instances”) in the Nova cloud. In more specific terms, this is the size of the instance (vCPUs, RAM, Storage, etc.) that you will be launching.
Coming from the ruby/ruby on rails world, i’ve been a bit lost when it comes to the python development process used in the openstack project. One of the biggest hurdles has been the usage of virtualenv in the workflow. Basically, virtualenv lets you create a stable configuration of python libraries (eggs) much like freezing gems in your rails application. The pitfalls here is that you need to integrate it’s usage into your development flow (activate/deactivate environments), it can take some time to recreate environments if you use a lot of eggs (like nova does) and it seems pretty fragile (it lives in repo and takes some chicanery to avoid duplicating in each bzr branch).