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:
- API implementation vs specification
- Building up coverage on continuous integration
- 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.
Rob Hirschfeld 