Lead Image © alexskopje, 123RF.com

Lead Image © alexskopje, 123RF.com

Do You Know Juno?

What's new in OpenStack 2014.2 "Juno"

Article from ADMIN 24/2014
By
The OpenStack cloud platform plays a major role in the increasingly important cloud industry, so a new release is big news for cloud integrators and admins. The new version 2014.2 "Juno" release mostly cleans up and maintains the working model but adds a few innovations.

OpenStack no longer needs an introduction for system administrators working in the modern universe of the cloud. The open source cloud platform, which was originally created by Rackspace, is now supported by several leading cloud providers. The OpenStack project [1] relies on a strict cycle. New releases appear in April and October no matter what the cost. To date, the release manager, Thierry Carrez, has kept the project on schedule, and the latest OpenStack 2014.2 "Juno" release appeared on October 16.

Conservative Renewal

Juno continues in the OpenStack tradition as a carefully extended OpenStack distribution. The good news for admins is that the existing APIs remain compatible with those that are already in place. So if you use applications that talk directly to the APIs, you can continue to use them in Juno. All told, the amount of work involved in upgrading from the previous Icehouse edition to Juno is quite manageable.

After the chaos of the first versions of OpenStack, the developers understand that it is conducive to the prestige of the project if you leave no stone unturned between two releases. If things change, the developers announce the changes clearly, and at least one version in advance – enough time to prepare carefully and professionally for an upgrade.

Neutron

The Open vSwitch driver in OpenStack's Neutron networking component was tagged as deprecated in Icehouse. Juno no longer contains the driver, because it has been replaced by the "Modular Layer 2" framework, which is usually just called ML2 (Figure 1) . If you have a cloud, that uses the old openvswitchdriver, you need to switch to ML2.

Figure 1: The old Open vSwitch plugin is finally history in Juno. Replacing it is the ML2 plugin, which admins now have to change to, if they have not already done so.

The Layer 3 agent finally inherently supports high availability, a feature for which admins have long been waiting. Up to and including Icehouse, Neutron didn't worry at all about failures of the network node that isolated the active VMs from the outside world. If you wanted to use high availability (HA) on Layer 3, you had to work with tools such as Pacemaker, which rarely resulted in satisfactory results, but it did add more complexity to OpenStack scenarios.

The Neutron Scheduler now ensures that L3 networks automatically switch to other systems should the primary host fail. The developers have garnished the feature with plugins based on VRRP, Conntrackd, and Keepalived; when this issue went to press, it was still uncertain whether all plugins would actually be included with Juno – for example, the internal project review was not completed for the Conntrackd plugin. As a general rule, though, Neutron will have HA features for L3 networks in Juno, and you can regard this change as a milestone (Figure 2).

Figure 2: The Layer 3 Agent in Neutron supports HA capabilities, which it provides to external networks through services such as Keepalived and protocols such as VRRP.

Juno also brings other Neutron changes: New drivers for a whole bunch of network hardware, including Arista, Brocade, and Nuage, are on board, as are new load-balancing drivers for appliances by A10 Networks. In Juno, Neutron thus grows much closer to devices that commonly appear as infrastructure in data centers.

Keystone and More

Keystone provides identity, token, catalog, and policy services for OpenStack. Behind the scenes, Keystone is a kind of root application; without it all the wheels stand still. For Juno, the Keystone developers came up with several gimmicks, the most important being basic support for a federation model.

In simple terms, the federation model works as follows: Keystone identifies a user by reference to login credentials and issues a matching token. With this token, the user turns to a different, remote Keystone instance that validates the token and provides the user access to the local cloud. Unfortunately, this feature is still marked as experimental for Juno, but the function should be officially available in the upcoming K release or earlier.

More improvements in Keystone include improved LDAP support and compressed tokens, as well as many changes to the version 3 API. Also, the hypervisor drivers for KVM on Libvirt, VMware, and Hyper-V in Nova have been treated to new features. Hyper-V VMs can now be restarted by soft reboot; previously, only a hard reboot was possible.

The upcoming K version of OpenStack will introduce a feature named "Scheduler as a Service," which is based on the component that is still called the nova-scheduler in Juno. To be able move forward, the Nova scheduler has already undergone a major overhaul in Juno.

Buy this article as PDF

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

Buy ADMIN Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
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”>
	</a>

<hr>		    
			</div>
		    		</div>

		<div class=