RAID – Automatically set RAID configuration parameters depending on how the system will be used.
Support for LSI controllers
Single and Dual RAID configuration
BIOS – Automatically set BIOS settings depending on how the system will be used.
Configuration setting for Dell PE series systems
Out of Band Support- Configure and manage systems via their OOB interface
Support for IPMI and WSMan
RPM Installation (it riseth again!) – Install OpenCrowbar via a standard RPM instead of a Docker container
Salt integration – OpenCrowbar can install Salt as a configuration tool to take over after “Ready State”
Chief Provisioning (was Chef Metal) – OpenCrowbar driver allows Chef to build clusters on bare metal using the Crowbar API.
Automated smoke test and code coverage analysis for all pull requests.
And…v2.1 is the first release with commercial support!
RackN (rackn.com) offers consulting and support for the OpenCrowbar v2.1 release. The company was started by Crowbar founders Greg Althaus, Scott Jensen, Dan Choquette, and myself specifically to productize and extend Crowbar.
While I cannot speak for my employer, Dell, about Crowbar; I continue serve in my role as a founder of the Crowbar Project. I agree with Eric S Raymond that founders of open source projects have a responsibility to sustain their community and ensure its longevity.
In the open DevOps bare metal provisioning market, there is nothing that matches the capabilities developed in either Crowbar v1 or OpenCrowbar. The operations model and system focused approach is truly differentiated because no other open framework has been able to integrate networking, orchestration, discovery, provisioning and configuration management like Crowbar.
It is time for the community to take Crowbar beyond the leadership of a single hardware vendor, OS vendor, workload or CMDB tool. OpenCrowbar offers operations freedom and flexibility to build upon an abstracted physical infrastructure (what I’ve called “ready state“).
As a Crowbar founder and its acting community leader, you are welcome to contact me directly or through the crowbar list about how to get engaged in the Crowbar community or help get connected to like-minded Crowbar resources.
I was part of the Dell contingent at the OpenStack design conference earlier in the month. The conference opened a new chapter for the project because the number of contributing companies reached critical mass. That means that the core committers are no longer employed by just one or two entities; instead, there are more moneyed interests rubbing elbows and figuring out how to collaborate.
From my perspective (from interview with @Cote ), this changed the tone of the conference from more future looking to pragmatic.
That does not mean that everything is sunshine and rainbows for OpenStack clouds, there are real issues to be resolved. IMHO, the top issues for OpenStack are:
Ensuring that we can deploy consistently in multi-node systems
Getting contributions from new members
Figuring out which projects are core, satellite, missing or junk. [xref 2014 DefCore]
Of these issues, I’ve been reconsidering my position favoring API via Implementation over specification (past position). This has been a subject of debate on my team at Dell and I like Greg Althaus’ succinct articulation of the problem with implementation driven API: “it is not fair.” This also ends up being a branding issues for OpenStack because governance needs to figure out which is a “real” OpenStack cloud deployment that can use the brand. Does it have to be 100% of the source? What about extensions? What if it uses the API with an alternate implementation?
Of the other issues, most are related to maturity. I think #2 needs pressure by and commitment from the larger players (Dell very much included). Crowbar and the deployment blueprint is our answer #3. Shouting the “don’t fork it up” chorus from the roof tops addresses contributions while #5 will require some strong governance and inevitably create some hurt feelings.
I’m not going to post OpenStack full conference summary because I spent more time talking 1 on 1 with partners and customers than participating in sessions. Other members of the Dell team (@galthaus) did spend more time (I’ll see if he’ll post his notes).
I did lead an IPv6 unconference and those notes are below.
Overall, my observations from the conference are:
A constantly level of healthy debate. For OpenStack to thrive, the community must be able to disagree, discuss and reach consensus. I saw that going in nearly every session and hallway. There were some pitched battles with forks and branches but no injuries.
Lots of adopters. For a project that’s months old, there were lots of companies that were making plans to use OpenStack in some way.
Everyone was in a rush. There’s been something of a log jam for decision making because the market is changing so fast companies seem to delay committing waiting for the “next big thing.”
Service Providers and implementers were out in force.
IPv6 is interesting to a limited audience, but consistently injected.
While IPv6 deserves more coverage here, I thought it would be worthwhile to at least preserve my notes/tweets from the IPv6 unconference discussion (To IP or not to IPv6? That will be the question.) at the OpenStack Design Summit.
NOTE: My tweets for this topic are notes, not my own experience/opinions