If you’re in Austin on 7/20 then come to the 2011 ATX CloudCamp @ 6pm (Downtown)
In addition to the normal great unconference format, I’ll be giving one of the lightning talks. My topic will be about Cloud Operations for OpenStack.
Here’s a copy of my CloudCamp 07 2011 preso. Unfortunately, the video was not complete so I can’t include it.
As part of our Agile/Lean methodologies, our team at Dell is highly invested in automated testing and continuous integration. We’re running Jenkins to coordinate builds and EVERY CHECK-IN launches our full integration suite that tests our system end-to-end. It may not be typical, but I don’t consider that to be particularly note worthy because it’s best practice. (Rob’s note: if you write code and don’t think you have the authority then you need to geek-up and just do it – that’s our MO at Dell)
It’s important to understand that since Crowbar is an installer, every check-in does a FULL CLEAN INSTALL of all the Cactus OpenStack components. Our verification requires that we test OpenStack because that’s our #1 exit requirement. Consequently, we have built an automated build system that does a continuous integration test of a full, multi-node Nova/Glance/Swift deployment.
Automated end-to-end integration tests of OpenStack are a very handy thing!
In the last few weeks, we’ve heard from Dell internal groups and partners who are contributing to OpenStack Diablo that they want to leverage our work in continuous integration. This will allow them to make sure that their development work does not regress other functions. It’s a significant opportunity to ensure that we can collaborate between organizations. It also promotes early development and distribution of Diablo installation scripts.
To support this in Crowbar, we are already planning incorporate more sophisticated revision control (likely based on Git) into Crowbar.
Note: YES, we consider our CI scripts to be part of our open source code.
As part of our commitment to open source, Dell is a sponsor of OSCON 2011. The Dell OpenStack Cloud team will have a booth presence with our well-travelled Crowbar Install rack (now with BOTH PowerEdge C6100 & C6105s). We’re doing our famous 30 minute OpenStack installs and handing out goodies including USB keys.
Joseph George (@jbgeorge) and I are speaking:
We’ll be giving specifics about how Crowbar works to deliver the Dell OpenStack Cloud Solution including a narrated demo and details about how the community can extend Crowbar using barclamps.
Note: Stephen Spector (opnstk_com_mgr), the amazing OpenStack community manager, wanted me to remind everyone that we’re celebrating OpenStack’s 1 year anniversary with activites at OSCON. He’s asking for video commentary about OpenStack and RSVPs if you can attend the events. More at OpenStack Blog.
My whole team is working feverishly on the final touches of Crowbar before we turn over the keys. We’re putting it through a complete release cycle (extensive QA, customer pilots, documentation, etc) because internal Dell consumers are expecting that level of finish.
For those in the community eagerly waiting to see the code, I hope you like the extra polish (for example: I18N, user & deployment guides, bundled continuous integration scripts, and months of testing).
RUMOR CONTROL NOTE: Crowbar is NOT limited to deployments on Dell products!! Our BIOS and RAID barclamps are, of course, targeted and licensed for Dell customers. The OpenStack and other barclamps will work on any gear that can run Chef Client.
Tonight I was working on the user guide and thought I would share the graphic and text describing how a barclamp gets deployed.
The figure shows the entire of a barclamp within the Crowbar user interface. A Barclamp defines the capability for a service but cannot be deployed. To deploy a barclamp, you must create a Proposal. Once the proposal is created, you must selection nodes to operate on. As discussed in the next sections, you may also edit the Proposal’s attributes as needed.
Applying the Proposal tells Crowbar to deploy the proposal onto the nodes. While deploying, nodes return to the Ready state when deployment is completed. Once a proposal has become an Active Role, you cannot edit it. You must delete the Role and repeat the Apply process
I can’t show you the really cool Overview screen yet, but here’s the one that replaces the one we’ve demo’ed before. The nodes are grouped by switch and ordered by port so it creates a very nice “rack” layout if your wiring is organized.
Props to Jon Roberts (@emptyflask) for his excellent UI work!
Ken Pepple (@ken_pepple) did a great write up of the Nova architecture. Read it if you’re looking for information about how Nova parts fit together.
It’s awesome to see new deployments of OpenStack so I wanted to point out Cybera’s post about their OpenStack efforts!
Everett Toews does a nice job talking about the rationale for their decisions including some analysis of their hardware and vendor selections. Of course, I’m also happy to have them posting links back to my Dell team’s white paper and content.
I wanted to highlight one point that Everett makes:
“Is this the best mix of hardware possible for OpenStack? As always the answer is, “It depends.” It depends primarily on your the use cases for your cloud. We think we got a good mix of hardware but time will truely tell if it was the best mix possible for DAIR.”
I strongly agree, we (Dell) are still recommending starting with a smaller set general purpose hardware config that can be easily repurposed. Once you’ve figured out how your application maps into OpenStack then we’ll be ready to work togther to tune that order for 1000s of servers.
I’ve been getting a lot of questions about Apache LibCloud and RedHat’s DeltaCloud vs. OpenStack. While all of these projects offer APIs, only OpenStack is based on an implementation.
Having an implementation means that the API is reflected by code that delivers the functionality of the API. This means that the implementation based API more closely reflects the actual workings of the system while the “pure” API must abstract the working of multiple systems. The API only approach ends up having to become a least common deminator instead of a vision of the pure use cases.
LibCloud and DeltaCloud are important and useful. They provide abstractions that help developers write applications without being tied to a specific cloud vendor. While lack of lock-in is a concrete benefit, it comes at a price. The price is that the API shim cannot expose features that differentiate the platforms. This may represent a significant loss of functionality or performance.
When developers implement directly against an implemented API, they can take advantage of the full feature set of their target cloud. They can also test and verify more directly. These are significant benefits that result in richer, more robust and faster to market products.
Both approaches have their place and are needed in the market. If I needed to write against multiple clouds for portability then Libcloud is a slam dunk. If I needed rich features and an ecosystem then OpenStack or Amazon are better choices.
As promised, here’s the other drop in advance of our OpenStack team’s Crowbar release.
This is the second part of the Swift and Nova recipes that we are intentionally leaking out to the community.
USAGE NOTE: These recipes are designed to work with Crowbar! They are not intended to stand alone.
As part of our collaboration with Opscode, Matt Ray, has been merging our recipes into his most excellent OpenStack cookbook tree. If you want to see our unmerged recipes, we’re also posting those to our github.
In addition to our Swift recipes, you can now check out the Nova recipes.
ADDITIONAL USAGE NOTE: The Matt’s tree is more complete – these are released for reference only. They will ultimately be maintained as part of the Crowbar.
If you noticed the Citrix’ Olympus OpenStack announcement with Dell and Rackspace (see my #2s chasing #1s commentary) then you may be wondering if there is a Crowbar story there too.
Yes, there is.
Rob Hirschfeld 