OpenStack's Juno is out: But is it time to slow down the releases?

Available this week is Juno, the latest six-monthly release from the OpenStack open-source cloud project and with it come questions about stability and the upgrade cycle.
Written by Toby Wolpe, Contributor
Boris Renski: Why build new features rather than stabilise old ones? Image: Mirantis

With a host of new features, the launch this week of OpenStack's Juno is again raising questions about the impact of the cloud platform's frequent releases on its stability.

The OpenStack open-source project started in 2010, initiated by Rackspace and NASA, to create components for building public and private clouds on standard hardware.

It now involves a large developer community working on a variety of loosely-coupled projects and is backed by more than 200 vendors, including Cisco, Dell, HP, IBM, Intel, Oracle, Red Hat and VMware.

New in Juno, OpenStack's 10th six-monthly release, are features such as storage policies, a data-processing service for provisioning Hadoop and Spark, and initial features for network functions virtualisation (NVF) to aid network and telecoms service deployments.

However, the sheer number of new additions and the frequency of the OpenStack releases can end up hindering stability, according to Boris Renski, co-founder of OpenStack systems integrator Mirantis.

"This cadence of two releases a year — a new release every six months — is not necessarily a very good thing," Renski said.

"You take an upstream code base — if you take Juno based on our experience of previous releases — it takes a good six months of hard-core testing and bug-fixing to turn the upstream code base into something that an enterprise can consume that would be stable.

"By the time you're done with it, the new release comes out. So by the time we're going to productise Juno, the OpenStack Foundation is going to release Kilo. At that moment Juno immediately becomes rotten tomatoes and nobody wants it. Everybody wants Kilo — and then the cycle repeats itself.

"This ongoing obsession of the market, which is fuelled by the Foundation pushing and marketing every new release so hard, is something that could potentially kill the adoption."

Renski said steps need to be taken to help the ecosystem of adopters understand that a new OpenStack release is not for enterprise use.

"That's just upstream stuff. Don't touch it, don't use it. It might have features but it's not for use. It's for vendors to take and harden. They have to kill this notion that you have to stay on the bleeding edge. Unfortunately, there's a lot of marketing done by the Foundation to the opposite. Until this happens, you won't see stability," he said.

OpenStack chief operating officer Mark Collier believes progress is being made in addressing issues raised by the upgrade cycle.

"There are definitely different schools of thought on it. But there are a couple of things I've noticed over the past year. One is if you look at the people who are making products like distributions out of it, the time window from when the community produces an upstream version and when they turn it into a product is shrinking," Collier said.

"It used to be six months and now it's weeks. People are getting that model down and getting more tightly aligned between upstream and downstream — if you think of the product as downstream.

"The other thing that's starting to happen because of user feedback, the upgrade process is becoming a lot easier. So if you're on an older version and you want to go to the next version, in the past it was very difficult and that was another sore point of how fast it's moving as well."

Collier said the argument that continual improvements to OpenStack make it hard for users to stay on top of the changes is also being addressed.

"For the first time from [the] Havana to Icehouse [releases], you can do upgrading of the compute systems without disturbing the applications running on top. That was never possible before and that's a relatively recent development. Being able to upgrade helps offset some of the negative effects of that fast cycle," he said.

OpenStack executive director Jonathan Bryce said another important point is that the new features now being released have changed in nature.

"If you go back two years, each release was very different to the release before because there were feature gaps that the community was filling in. So there were massive new features coming in every six months," Bryce said.

"If you look at the last few releases, the biggest updates have really been around operations and management of an OpenStack environment. There have been big features in the releases but there have been a much smaller number of net new feature-adds. That makes it a lot easier for everyone involved to move along with the work from the community."

Mirantis' Boris Renski said the Foundation has understood some of the underlying issues and is putting in place measures with the creation of a stability team, which is not sponsored by any third-party organisation. But that step and the tightening of guidelines for accepting projects into the integrated release may be addressing only part of the issue.

"What needs to happen is that the Foundation and the Technical Committee together have to do something about the way they label and position their releases that would enable third-party vendors such as Red Hat or ourselves more time to stabilise the new realise," Renski said.

The roots of the problem lie in the origins of the OpenStack project and the desire of its community to match as soon as possible the features offered by platforms such as Apache CloudStack, according to Renski.

"Stability was an afterthought because you have to have a basic set of features for the product to be even viable. They very quickly built a lot of different features, a lot of new projects popped up. Ultimately, development velocity is a blessing and a curse," he said.

"The bad side is that it sprawled so quickly and so widely and there is this inherent obsession with building new features rather than stabilising the old ones, that the stability of all the different projects is a problem."

Nevertheless, OpenStack continues to hold a strong appeal, Renski said, because of its very wide vendor support

"That's really key because most companies adopt OpenStack because they see it as a glue for heterogeneous datacentre components. Out of all the fabrics out there, OpenStack is the one that has most vendors proactively developing and supporting drivers for it," he said.

"So if you have EMC, NetApp, or Ceph for storage, it doesn't matter, or if you have ESX, Xen, or KVM for hypervisor, it doesn't matter. There are drivers for all of these things into OpenStack.

"This notion of being able to glue together different components is ultimately the core value that OpenStack brings. The reason why it all stays together is because it's a solution that ultimately customers need."

More on cloud and OpenStack

Editorial standards