With corporations like SUSE, Red Hat, Canonical, HP, IBM, and Intel investing time and money in OpenStack, clearly this cloud computing platform is here to stay. On the other hand, OpenStack technological advances do not rank highly with many administrators.

The criticisms are always the same: OpenStack is not mature enough as a project to meet the challenges of the provider's daily grind. Some developers believe the money that comes from corporate funding is not always useful: Precisely because so many stakeholders want a say in OpenStack, the project is finding it difficult to formulate and implement its technological objectives. Therefore, the tension always builds up in the community whenever a new OpenStack version is announced, which typically happens twice a year, as was the case in April. OpenStack 2015 "Kilo" is the successor to OpenStack Juno, but what features does the revised OpenStack offer, and have the developers succeeded in solving some of the major problems?

The Big Tent

Possibly one of the most important innovations in OpenStack has nothing to do with technology: the OpenStack Foundation's Big Tent initiative. The image of a big tent underscores the fact that OpenStack wants to be understood as a catch-all for any project that is related to cloud computing. The implementation of the Big Tent initiative was preceded by lengthy discussions, especially within the OpenStack Foundation itself. Release manager Thierry Carrez describes the problem in an exhaustive but easily understandable paper [1].

Up until Juno, OpenStack comprised one major release, and only the officially integrated OpenStack components were allowed to use the title. Anyone wanting to integrate their component needed to pass through the incubation process and thus survive a number of tests. After finally completing a number of intensive checks, the path for promotion to an official OpenStack component was then clear.

However, so many sub-projects have requested admission to the project that the task of coordinating releases is becoming increasingly difficult. The backlog creates the impression that programs not yet integrated are undesirable, or at least not firmly anchored in the OpenStack community. This impression is not always accurate or desirable.

The policy applied thus far has actually prevented development: For example, two alternatives exist for the Ceilometer component (Figure 1), both of which offer metering for OpenStack. So far, neither of the projects – StackTach and Monasca – has gained official status, because they offer an alternative to previously existing functionality.

Figure 1: Ceilometer uses a design that not even its original author supports, but nothing changes in Kilo.

Four-Point Program

The Big Tent initiative will mean that any project can call itself an OpenStack component as long as it observes four very important rules:

• The project must identify with the OpenStack goals, and it must be interested in improving OpenStack's reputation.
• The licensing and development models and the developer tools (e.g., Gerrit for code review) must be identical to those used by the OpenStack project.
• Basic API compatibility, for example, to OpenStack's Keystone identity service, must be in place.
• The projects accept the authority of the OpenStack Technical Committee.

Big Tent has already led to heated discussions in the community. Although proponents of these rules are happy to see the project moving in what they consider the right direction, opponents are throwing their hands up in horror. The big tent is normally full of clowns, they say, and the Big Tent initiative is equivalent to the OpenStack Foundation's giving up all control over the technical architecture of OpenStack. They equate the initiative to an end-of-line sale of the OpenStack brand.

The project is looking to counteract this risk with tags. In the future, administrators will be able to tell whether projects are part of the six-month release cycle, or are following their own cycle, simply by looking at the tags. A list of tags is available online [2].

In the case of Kilo, you can say that things are never as bad as they seem: Kilo mainly comprises components that were integral components of previous versions, with the Ironic provisioning tool added on top. Diversification in line with the new rules is thus only likely to take effect slowly after the Kilo release. The time to talk about this topic again will be after the OpenStack Liberty release in October 2015.

Ironic: Finally!

Ironic is one of the major highlights and the only official, new component in Kilo. Ironic only works in combination with Nova, which is the component that manages computing power in OpenStack clouds. If you want to use a virtual machine, Nova finds a matching host and launches the virtual system on it. So far, Nova has been restricted to virtual machines. Ironic adds the ability to handle physical systems. Metal is handled in OpenStack just like a virtual machine: Both can be managed centrally in a web interface.

How much sense Ironic makes remains to be seen. It was created by HP and developed in combination with Triple-O, which stands for OpenStack on OpenStack. The actual hardware in a setup of this kind is an "Under-Cloud" that is controlled by OpenStack on which separate "Over-Clouds" can then be launched for customers. You can try out Ironic with little effort, but if you want to leverage the solution's full potential, you need Triple-O.