« Previous 1 2 3 4 Next »
The new OpenStack version 2014.1 alias "Icehouse"
House of Cool
Neutron: The Eternal Construction Site
OpenStack's Neutron networking service also saw many innovations. The component responsible for software-defined networking (SDN) is well-known for implementing many useful SDN features.
Neutron is also notorious for its complexity, particularly among cloud newbies: The learning curve is intense, and Neutron throws many well-known network conventions overboard. Many cloud admins are likely to be heartily unimpressed by the hustle and bustle of Neutron, because more functionality inevitably comes at the price of more complexity.
In Icehouse, the order of the day seems to be IPv6. To date, IPv6 support was virtually non-existent; but more support appears with the Icehouse release, and Neutron will continue to support IPv6 networks in the future. Routing advertisement will make it possible to connect virtual machines directly with an IPv6 address. (In the past, the lack of IPv6 support has been a showstopper for many enterprise environments.)
The second major Neutron innovation is built-in SDN support. Neutron supports the OpenDaylight SDN environment – more reading for admins to catch up on. In OpenStack Icehouse, the legacy Open vSwitch module is officially tagged "deprecated"; the old vSwitch will likely be completely missing in the Juno release that will follow Icehouse in October. In the previous Havana release, the Neutron developers gave their baby a new framework that ultimately emerged from the wish to avoid code redundancy. Earlier, virtually every module implemented its own basic functions; duplicate implementations were thus inevitable.
The "Modular Layer 2" framework circumnavigates this problem by using an API to provide basic functions that all modules can use. In Havana, the bulk of the Neutron module had already been ported to ML2; the developers have now pushed on with this effort in Icehouse and are preparing to remove non-ML2 plugins for Open vSwitch. In this context, it is almost grotesque that the granddaddy networking component "nova-network" is still not "deprecated" in Icehouse, despite repeated announcements to the contrary; the developers expect the severely out-of-date nova-network to hang on in OpenStack for at least another 12-18 months.
OpenStack Icehouse is the first OpenStack version in which the Neutron service has rudimentary support for "Regions." Regions are used in OpenStack to logically group individual computers on the basis of specific, predetermined properties, but previous versions of Neutron completely ignored region membership. Icehouse offers the option of adding a "region" flag to the database for individual ports in Neutron; Juno will draw considerably more value from OpenStack regions. Additionally, the latest Neutron comes with new plugins and includes significant updates for several existing plugins.
Horizon Keeping Pace
Many of the changes in Neutron and Nova required adjustments in the Horizon web interface or the dashboard (Figure 2). The dashboard developers clearly aimed for continuity: The Icehouse dashboard enhances the functionality of features that already existed in Havana. The VPNaaS plugin has been updated; and the options for editing the "flavors," that is, preconfigured profiles for virtual machine hardware, are also improved in Horizon.
Cinder and Keystone
The block storage service Cinder and the Keystone authentication service typically putter around unnoticed in the background; but, that is no reason to ignore them in this discussion of new features. In Keystone, the new API (Version 3) has seen some updates, and it looks likely the new version will oust the currently more popular version 2 API in the long term. The developers are still not forcing users to make a decision; the old API will continue to work in Icehouse without restriction, even if it is tagged as "deprecated." (It is still unclear whether the legacy Version 2 API will be dropped in the upcoming Juno release.)
Another security-related change is that tokens are now only valid for one hour, as opposed to 24 hours with previous versions. OpenStack's own components can easily task Keystone with issuing a new token if in doubt. However, if you build your own software on top of Keystone, you will need to ensure that the software can cope with the shorter token validity period.
As has often occurred during recent release cycles, Cinder sees some new drivers and updates for the existing drivers: You can use HP's MSA 2040-SAN storage system, as well as additional QoS parameters for HP's 3PAR storage and SolidFire storage solutions. Fibre Channel support, which was already introduced in Grizzly, is enhanced to handle Fibre Channel storage zoning directly from within OpenStack.
« Previous 1 2 3 4 Next »
Buy this article as PDF
(incl. VAT)
Buy ADMIN Magazine
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Most Popular
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.