Do You Know Juno?

What's new in OpenStack 2014.2 "Juno"

Triple O

HP's triple O (the triple "O" stands for OpenStack On OpenStack) [2] relies on Ironic at its core, but Ironic actually only becomes really convenient with Triple O, which comes with a GUI by the name of Tuskar (Figure 4). Triple O is a very active subproject within the OpenStack project; in recent months, its developers have completed huge amounts of work to make OpenStack On OpenStack a workable solution.

Figure 4: Tuskar is part of Triple O and seamlessly integrates the various bare metal services with Horizon, the OpenStack dashboard.

Ironic is definitely on its way to becoming an official core component; that is, it will soon be part of the innermost circle of the OpenStack environment. However, the path Ironic had to tread before receiving this accolade was anything but short: HP participated extensively in Ironic's development. In the future, Ironic will offer a genuine alternative to provider-specific solutions, allowing Triple O to become one of the great OpenStack players.


Once again, OpenStack presents a new version as a conservative advancement on its predecessor; Juno also has a few smart additional features on top. The good news for admins is: if you can manage Icehouse, you will have no difficulty with Juno, because there are hardly any differences.

The removal of the legacy Open vSwitch driver can pose a challenge in various setups; if you did not listen to the developer warnings in Icehouse, you need to do so now. The remaining changes, however, fit seamlessly into the picture; updates from Icehouse to Juno are said to be no more than moderately challenging. The box titled "OpenStack and Automation" describes what the latest release achieves in terms of automation.

OpenStack and Automation

Once a cloud with dozens, perhaps hundreds, of virtualization hosts has been built, it is impossible for admins to take care of each individual machine manually. Most large-scale OpenStack deployments thus rely on automation. The degree of support for popular automation management tools varies: Chef works well now after SUSE and Dell put much time into supporting it. Solutions with major quality differences exist for Ansible [3], SaltStack [4], and the many other alternatives.

But Puppet is still the standard for automation in OpenStack . The puppet-openstack modules are maintained on StackForge [5] and use the same development tools used with OpenStack and its other components.

The Puppet modules that Juno will support have undergone a major revamp – consolidation is the key word. Of course, a few new functions and new parameters have been added for the modules. Perhaps the most significant advance is the introduction of a meta module by the name of puppet-openstack-lib that offers shared functions for all Puppet modules.

Every OpenStack module has to support similar tasks, such as interfacing with a MySQL or PostgreSQL database. Often, different modules use the same code block for the task, which is thus copied several times. This was inefficient and in particular meant that changes always needed to be integrated in many places in the modules. The new puppet-openstack-lib meta module means developers can maintain a single version of the code that is then used by all modules.

Keep in mind that if you already have a Puppet-based OpenStack cloud, you will have to expend significant energy upgrading to Juno. The modifications to the modules require many changes, depending on the local site manifest. If you are planning such an update, you would do well to assign a generous time allowance for the Puppet item on your to-do list.

All told, Juno is a successful release. These tiny-step releases are not popular across the community, by the way. You will often find critical comments on the mailing lists, because introducing new features takes quite a while with the current setup, and several releases can see the light of day before they are actually ready for use. This conflict could fuel debate in the community in the future – but for admins, the current model makes far more sense.

The Author

Martin Gerhard Loschwitz works as a Principal Consultant at hastexo. His work focuses on high-availability solutions, and in his spare time he maintains the Linux Cluster Stack for Debian GNU/Linux.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs

Support Our Work

ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.

Learn More”>


		<div class=