Is OpenStack Becoming TrumpStack?

You’re probably thinking this is a clickbait title, and admittedly I did take some liberties with the current political adventures happening. The concept I’m putting forward here is that the OpenStack community is often being divided on some very important and challenging areas.

The reason I call this TrumpStack is that there is a strong representation of what we may refer to as establishment OpenStack advocates, who are firmly holding onto the hope that it will become an AWS competitor inside the on-premises data center and in the public cloud realm as well. This group is largely made up of developer-focused folks. A lot of the consumers from this crowd lean towards entirely API-focused use of OpenStack. They tend to work higher up the stack in the application tiers.

On the other side of the aisle is the citizen brigade who wants the private cloud capability, and also wants it to support some of the enterprise capabilities. These are the elusive “Enterprise” customers. They don’t see why there can’t be high availability features baked into the core of OpenStack projects. The Enterprise consumer doesn’t understand why we should be pushing back on packaging and making the deployments simpler even if it adds some extra layers. This group is largely made of of traditional virtualization administrators and architects. This audience has had a tendency to think bottom up when looking at infrastructure solutions.

Here are just a couple of examples that have popped up recently that help to show where there seems to be a dichotomy in the ecosystem.

Packages or Build From Source?

This discussion came up at the documentation design session which I attended in Austin. There was a genuinely visceral reaction when the topic came up around the OpenStack Install Guides hosted at which show the installation process for multiple Linux derivatives.


The seasoned developers in the room had a strong push towards wanting to create a guide which will use a build-from-source methodology to ensure that the results have a higher chance of being current and consistent. The response from the other faction in the room (myself included) was that moving away from packages towards building everything from source would create an even higher barrier to entry, and will alienate many newcomers to the platform.

We can see that there are very good reasons for the build-from-source. We can also see why using packages is much more convenient for installing and building. My opinion is that anything we do to create more friction and process around the installation and adoption of the platform reduces the chances of it growing.

Fully packaged OpenStack builds and leveraging projects like Fuel can be the way for us to accelerate the adoption as well, but the grass roots sysadmin adoption will be found by making those first few steps as seamless and frictionless as possible. The discussion on the documentation went quite well considering the tumult that was possible as many opinions were put forward. The end result at this juncture was to continue to support the current guides, but to also review better ways to organize them for consistency and better UX flow.

We Name our Cattle on This Farm

Tired of hearing about Pets vs. Cattle? Most of us are. The underlying concept is important. While OpenStack, and most private and public cloud platforms, is geared towards workloads that have resiliency build into the application, many of the folks in the industry just aren’t there yet. The question comes to OpenStack advocates now: Should we push away potential adopters of the platform because they may have workloads that aren’t entirely appropriate for a typical “cloud” infrastructure?


The only thing more contentious than the Pets vs. Cattle debate is trying to find who originated the phrase. For the record, I also try to steer folks away from this phrase, because in some highly populated parts of the world, cattle are much more highly regarded and protected than pets.

Feature Creep and the Big Tent Challenges

When you build an open platform which has the power to get into a feature creep situation. That is where too many voices are involved and take the project in multiple directions. Sometimes they are parallel development streams, but they are multiple points of focus that can cause contention between features.

If you search for projects within the incubation phase, you will find that many projects present the same hopeful goal. These parallel projects also present entirely different methods. How many different ways can you achieve a feature? Well, that depends on who is leading that feature development. What are the key requirements? Which is the base from which to define the “standard” of how to mark it feature-complete?

That’s the interesting thing about democratic solutions. If you look at the Whitehouse petitions site, there are a lot of rather odd petitions on there, but if they get enough signatures, they have to be evaluated by the Whitehouse administration.

Speaking of voting…

Voting Challenges: The Summit Selection Issue

This one came up with the most recent Call for Proposals for the OpenStack Summit in Barcelona from October 25th-28th. in the past, you were able to submit your proposal, and once the deadline arrived, you were able to share out your sessions for voting. Voting was open to anyone with an OpenStack ID. This meant that you had to be a part of the community in one way or another to be able to vote.

For this round, the voting was no longer done by login. It also didn’t provide the ability to give links to your specific sessions in the voting mechanism. To top that off, there was also an interesting discussion sparked by Randy Bias on Twitter about it.

The core of the conversation is around who should be choosing the content that appears at the Summit. We saw some opinions that it should be chosen by track chairs, and many feeling that the process should go on as it did in the past. There were some oddities around the tooling and UX from the previous voting systems.

One suggestion came in that I think could be positive: attendees of the Summit are the voting public. This would reduce the “ballot stuffing” as some call it where a company with significant size of staff could add many votes in favour of their own presenting staff members.

Why Do I Call this TrumpStack?

Baiting headline aside, lets think about what is happening. We have a system being developed which was born of the creators as an open source ecosystem. Everyone has a level playing field, and technical committee members are chosen by vote to make decisions to give technical direction to the sub-projects. The OpenStack model is good, until suddenly there is an onrush of people who want to use it, but they also want features that don’t necessarily fit with what the technical committee membership agrees should be under the hood of the OpenStack core.

We have a citizen uprising to the establishment (albeit an open source and quite a well-working ecosystem IMHO). Even the best open source projects can be steered when the growth becomes rapid. This recent tweet from Kelsey Hightower shows regarding
challenges in the container standardization gives another good example:

I’m on both sides of the argument in parts here. Standardization is important to the overall ecosystem. I applauded Alex Polvi for his work to drive Rocket and the surrounding specs that support it. I also see that the team at Docker could find themselves at the whim of a slower moving standards body which could be seen as dampening innovation.

I wish that I had the solution. This isn’t exactly some kind of Kobayashi Maru or anything, so we have to ease back on the deep political arguments. I also recognize that the role of the PTL and Technical Committee for OpenStack do find themselves in a difficult spot.

Do we further the will the of the people which could steer the ship into some more choppy waters? Do we treat it as a benevolent dictatorship and take a more aggressive approach to reduce feature creep.

There are a lot of ways that we as a community can help with this. I continue to be thankful for the work of the PTLs, developers, supporting vendors, and everyone who contributes to the OpenStack ecosystem in any way. In my opinion, we all have a stake in this.

That’s the interesting thing about democracy in open source. We may not like the opinions on any side of the ecosystem, but we have to listen, and sometimes we have to make difficult choices. Looking forward to seeing the continued growth of this very exciting and open community.

TechForward Crash Course OpenStack Session at VMworld 2016

If you’re going to be at VMworld in Las Vegas, I’ve got a fun and informative set of demo sessions running for a new initiative called TechForward.  Please click on the link below to go to the Eventbrite page for the session.

techforward-openstackJoin me on Wednesday August 31st at 2:00 PM PT to watch a demo of OpenStack, and to get caught up on where the open source private cloud platform is and why it matters to you.  The demo will show some of the basics of the OpenStack, and we will review the concepts and features with some great discussion in the booth presentation theater so you don’t even have to leave the expo hall.

You don’t need a ticket to attend, but it is helpful for me to understand who will be there, plus it also gives you the ability to add to your calendar so you can get a reminder on the day of.

Looking forward to seeing you in Las Vegas!  Look for more TechForward posts including one on Mesosphere DC/OS, and one on Kubernetes as well.

Keep watching for more updates as well in the coming weeks.


Presentation – OpenStack Summit Austin – Couch to OpenStack

For the folks who couldn’t attend the live event, here is my presentation from the OpenStack Summit in Austin for the Couch to OpenStack session.  Video and presentation below.  Hope that you find it helpful!



OpenStack: The Black Album

This year will signal the shift towards a more enterprise-oriented OpenStack ecosystem. It will come in many ways. At the same time that we see the warmer embrace from enterprise customers, a long sought after market, we also see divisive chatter among the community that OpenStack is at a dangerous crossroads in its direction of development.

Success Divides the Fan Base

metallica-blackWhen San Francisco metal band Metallica released their Black album in 1991, it was met with critical acclaim, but also with disdain and resistance from many long-time fans of the band.

Why did commercial success suddenly signal that the band was no longer the band that had drawn so much of a fan base up to that point? Had they truly “sold out” as the early fans seemed to think? Or, had they just evolved?

With the guidance of successful producer, Bob Rock, Metallica reached 16 million copies sold of their fifth studio album, and an entirely new fan base. This was what allowed them to grow, evolve, and sustain their careers and brand for 24 years more. And there is no sign that they are done either.

In my opinion, OpenStack is looking for its Bob Rock, and will find it this year.

OpenStack Will Move Up the Stack

As the IaaS layers solidify, it opens the door for many of the growing efforts to embrace PaaS and container integration under the big tent.

This is where the proverbial rubber hits the road. Less effort on plumbing, and more of a concerted effort to move to what really matters, which is the application layers.

Let’s be honest, the greatest buildings in the world are only great because they draw tenants. A beautifully designed building that sits empty is one that will fail. The same goes for private cloud and IT infrastructure.

Cloud Management Muddiness

what-exactly-is-a-cmpToo many products are being touted as Cloud Management Platforms. They aren’t. They are mostly orchestration frameworks that enable some workload automation, but the name is misleading.

Cloud Management implies that the cloud itself is also within the control of the platform. None of those to date have bridged that gap. I believe that we need to label the CMP as an AWMP. The Application and Workload Management Platform is one that brings the orchestration closer to self-service.

When I see vRealize, CloudForms, and AWS tools in the same graph, I know that we are using the wrong measurements to classify a CMP.

The need for vendors to be labeled as “Cloud” has forced the vagueness of this category. It’s no better than when every vendor tacked on a 2000 to their product name to seem relevant and forward-leaning.

Success of Private Cloud is up to Us

only-youOpenStack is ready. If anyone believes that it isn’t, then the reality is that they aren’t ready to consume IT in the way that IaaS is offering it.

There are lots of options to buy packaged OpenStack derivatives. It doesn’t need a team of engineers like many would have you believe. That’s just fear mongering. When vSphere made its early gains in the market, most of the admins that I worked with and spoke with had little to no Linux experience. That didn’t stop them from embracing a Linux-backed hyoervisor.

Prepare yourselves, OpenStack is coming. It’s better to be making educated decisions now than to have it suddenly show up and leave you scrambling to catch up to the skills that could make you a private cloud rock star like I know you can become!