I attended Open Infra Days UK in London. When asked to extract a theme from the two days my response boiled down to "people want to run Kubernetes clusters and want the bits underneath to be low fuss." There were many more ideas passed around, but that one was there, either staring me in the face, or lurking behind the superficies.

This might tell us something about where the OpenStack community should be directing its development energy but, as usual, the true picture is more complex than that. For one thing, you can put a Kubernetes cluster on a collection of elastic and easily available VMs. OpenStack has been rather devoted to exactly that for years. The OpenStack provider for the Kubernetes cluster API is active and healthy. A presentation on Monday from Spyros Trigazis of CERN, explained how Magnum is being used to bootstrap many Kubernetes clusters on their very large OpenStack cloud.

But — at least for me — this was not a very telco-heavy or people-selling-to-telcos-heavy gathering. At those gatherings, milking every last hertz, bit and millisecond of CPU and network performance, achieved by describing the available hardware in excruciating detail, is the apotheosis of a vision of OpenStack as infrastructure manager.

This division between a) adequate (but not best) for many purposes (including Kubernetes) while simple to manage and consume, and b) capable of being the best for specific use cases while requiring complexity and knowledge to manage and consume has been commonplace in the history of computing. I can run several games well enough on an off-the-shelf PC, but if I have specific demands for resolution and frame rate I need to make well-informed choices about the details.

Throughout its history, OpenStack has been trying to balance the sometimes conflicting goals of being a general purpose cloud, simple to manage and use; and being a, well I'm not even sure what to call it: A manager for software defined data centers that vary in size from a little box at a cell tower to geographically disperse racks around the world.

There are plenty of people who work on OpenStack who want it to be (or it might be accurate to say "keep it") the open source cloud solution, but the economics of the situation don't always support that. Many OpenStack developers are employees of companies that somehow make money from OpenStack; by selling a packaged version or supporting or consulting on some piece of OpenStack that is being used in a private deployment. Yes, there's an increasingly visible and valuable section of contribution coming from individuals who are involved with running public OpenStack clouds, but over the history of the project these people have not been the majority.

This means that development is often driven by features that either give or merely give the impression of giving value to private and not-so-general purpose use cases. That's because those people have money to spend on use cases that can't be satisfied elsewhere. The big three cloud providers are so cheap for general purpose computing that it is difficult for OpenStack to compete. If you don't truly care about open source, OpenStack has to present either some very low barriers to use, or unique value propositions.

There's more money in the latter, so we've spent more energy on that than on lowering the barriers to use. It was inevitable, we shouldn't feel too bad about it. But we may now have an opportunity to change things: The basic orchestration functionality provided by Kubernetes is actually good. There will be demand for places to put clusters. Simple VMs or simple bare metal are a good choice. Having a diversity of options is good, OpenStack is one good option and it could be better. The scale of the demand could overcome the aforementioned economic limitations.

That suggests that we could do some things to help this along. Some of this is already in progress:

• Highlight and give greater attention to the several ways it's possible to build a Kubernetes cluster on OpenStack: Magnum, cluster API on VMs, and cluster API on bare metal.

• In some situations, invert the traditional relationship between Nova and Ironic. Make it easy to host VMs, or not. Whatever works. First comes Ironic, then if you need VMs, comes Nova.

• Explore simpler "get me a VM" solutions that operate at the same level as Nova. The end user gets a choice. If they want a fancy, hardware-aware, compute service, they use Nova. If they don't, they can use something else.

I started exploring the "something else" with etcd-compute. It started out as a joke but then it worked and was something other than funny.