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.solinea.com/2013/06/15/openstack-grizzly-architecture-revisited/.
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: Object Store (codenamed “Swift”) allows you to store or retrieve files (but not mount directories like a fileserver).
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.