Whew! Releasing a new version of any product can be an exhausting experience – but once released, the product manager gets to crow about it! Mirantis released version 3.2 of Mirantis OpenStack on October 21st and it’s an amazing release full of new capabilities and value.
What is Mirantis OpenStack?
One of the big moves we’ve made is to formalize what Mirantis OpenStack actually is. Mirantis OpenStack is made up of three items:
Fuel for OpenStack
Fuel is our lifecycle management application that deploys multiple OpenStack clouds from a single interface and then enables you to manage those clouds post-deployment. You can add nodes, remove nodes, or even remove an entire cloud and return those resources to the pool of available resources. Fuel also eases the complexities of network and storage configuration through a simple to use graphical user experience. Baked into Fuel are:
- Mirantis reference architectures that we’ve tested and certified to ensure that your deployed cloud can scale, is reliable and is production quality.
- An open and flexible library that enables customers to make configuration changes that may be more advanced or focused than the default choices within Fuel. This library also empowers organizations to fold additional drivers or integrations into the deployed environment.
Mirantis OpenStack hardened packages
These packages include the core OpenStack projects, updated with each stable release of OpenStack. Also included are
- Packages to ensure high availability
- Any defect fixes reported by our customers that may not yet have been merged into the community source.
- Mirantis-driven premium OpenStack projects (e.g. Savanna and Murano)
- Mirantis-certified partner plug-ins, drivers and integrations
Another benefit you get from Mirantis OpenStack as compared to some competitors is our broad support for operating systems, hypervisors and deployment topologies. We don’t restrict your choices to just one OS or one hypervisor type. In addition, you can choose the OpenStack roles you want on each available node.
In addition, Mirantis OpenStack offers a subscription to our world-class support with defined service level agreements based on the severity of your issue. For example, with premium support we guarantee a response in one hour for severity 1 issues.
Digging deeper into the features of Mirantis OpenStack
Here’s a more detailed look at some of the great features included in this version.
Expanded choice of Ubuntu, CentOS or Red Hat Enterprise Linux as the host Operating System for OpenStack
Fuel 3.2 has added support for deploying the Mirantis OpenStack hardened packages using Ubuntu 12.04 as a host Operating System for the OpenStack nodes. The Ubuntu 12.04 operating system is included in the ISO for Mirantis OpenStack, so you can select Ubuntu from the Releases window and deploy without requiring Internet access or downloading additional software. This expands your choices for deployment to Centos with Mirantis OpenStack hardened packages, Red Hat Enterprise Linux with Red Hat OpenStack or Ubuntu with Mirantis OpenStack hardened packages.
Guided deployment wizard to simplify environmental configuration
New in Fuel 3.2 is a guided deployment wizard that will walk you through the major decisions regarding your desired OpenStack configuration prior to deployment. This wizard enables you to make a choice about your OS and distribution, reference architecture, hypervisor, networking service, storage backend and an option to install related premium projects (Savanna and Murano).
Ability to combine multiple roles onto a single node for HW consolidation
To provide additional flexibility and options during deployment of your OpenStack Cluster, Fuel 3.2 now enables certain roles to be combined together onto a single node. Previously, for example, Cinder could only be deployed as a standalone node from the Fuel UI. Now, Cinder can be combined with a Controller or Compute node or Ceph can be combined with a Controller or Compute node.
To make this process even easier, we’ve added the ability to assign the same roles to multiple nodes in a single operation. Just select the unallocated nodes that you want to share a common role, choose the role and then apply. You can also group nodes by similar hardware types, allowing you to select all the nodes of a particular hardware configuration for role assignment with one click.
Once assigned, you can review the nodes and roles assigned to those nodes by grouping in a similar manner – either by roles or by hardware configuration.
In addition to role assignment, you can also configure the network interfaces or disk configuration for a set of nodes from the Fuel UI. Once you’ve selected one or more allocated nodes, the Configure Disks and Configure Interfaces buttons will become active if the nodes you’ve selected share a similar disk configuration or number and type of network interfaces (as appropriate).
Inclusion of Inktank’s Ceph software-defined storage system in the hardened packages and the ability to deploy Ceph via Fuel
Included now in the Mirantis Openstack hardened packages is Inktank’s Ceph software-defined storage system. Ceph can be used either as an object storage option for Glance or as a block storage option for Cinder. As you define an OpenStack environment through the Fuel UI, you may choose to use Ceph for one, both or neither of these functions. In addition, you may choose where to install the Ceph roles – either as a standalone node or combined with a Controller or Compute node.
Neutron (Quantum) as a deployment choice from the Fuel UI
Previous versions of Fuel enabled deployment of Neutron (Quantum) through the Fuel CLI Library. In Fuel 3.2, the ability to deploy Neutron as the network component for OpenStack has been elevated to the Fuel UI as well. Neutron can be configured to use Generic Routing Encapsulation (GRE) segmentation or VLAN segmentation from the deployment wizard. Additional settings can be manipulated through the Network settings tab prior to deploying the OpenStack environment.
Inclusion of the OpenStack Savanna and Murano projects in the hardened packages and the ability to deploy them via Fuel
Savanna and Murano are related Openstack projects initially led by Mirantis. Savanna enables on demand provisioning of Hadoop clusters that can run on top of OpenStack. Savanna includes support for many different distributions of Hadoop including Hortonworks, Cloudera and even Intel. This empowers Big Data solutions to take full advantage of the elastic nature of OpenStack. Savanna is currently a project that’s in incubation, but we’re confident that it will become a full project in OpenStack in a future release of OpenStack.
Murano enables windows based services to be deployed on top of OpenStack. These datacenter services include Active Directory, IIS, Microsoft SQL and ASP.NET. This enables companies to either provide developers or end users with Window’s based services that they either depend on, or as a tool for transitioning them away from legacy dependencies toward open source or other offerings.
Both of these projects are now included in the Mirantis OpenStack packages and can be configured for deployment on top of OpenStack through Fuel. Initial configuration is done via the Fuel UI, but Savanna and Murano also integrated into Horizon, enabling further configuration to be done natively from the OpenStack dashboard.
In addition to the ability to deploy Savanna or Murano, additional tests have been added to the OpenStack Health Check to confirm the successful deployment and operational status of Savanna and Murano.
Published API to Fuel for Create, Read, Update & Delete (CRUD) operations
The API originally created between the Fuel UI and Fuel CLI Library is now public and available in Fuel 3.2. This RESTful API enables auxiliary applications to activate standard CRUD operations (Create, Read, Update, Delete) to manage your cloud infrastructure through Fuel. Using Fuel you could, for example, create a cloud on demand, remove a cloud that was no longer needed or add nodes to and remove nodes from an existing cloud. This could be done either from a self-service portal or by your cloud operations staff. In addition to cloud deployment operations, you can also run the health checks on demand or collect log information for troubleshooting. Details on commands that can be executed through the API can be found in the extended development documentation.
Additional High Availability tests added to OpenStack Health Check
To confirm that a highly available deployment is configured properly and running as expected, an additional test module has been added to the OpenStack Health Check within Fuel. This group of tests can be run separately or along with the other post-deployment health checks and can be activated via the API for automated confirmation of high availability.
Extended configuration menu during Fuel Master Node install for network settings
Advanced customers deploying the Fuel master node into their own network setups with unique network parameters may need to specify a broader set of network settings (e.g. interfaces to use for PXE booting, IP address ranges, network masks, etc). Incorrect settings could result in permanent problems that are not easily corrected later. To ensure that these critical parameters are set appropriately for the Fuel master node, a full-featured configuration menu is now available during installation of the Fuel master node.
To access this advanced menu, you may optionally press a key when prompted during the first boot of Fuel Master Node. If a key is not pressed, the installation will continue automatically and the default values for parameters will be used.
This menu, once activated, enables configuration of the managed network, network interfaces, DNS settings and access to the operating system through a shell login. Once the parameters are saved, the installation continues.
Expansion of log management to include OpenStack logs and configurations
The types of logs collected by Fuel from the Logs tab has been increased to include the logs from OpenStack services. In addition, OpenStack configuration files are now downloaded when collecting the logs from remote nodes onto the Fuel Master Node. This collection is initiated from the Support screen on the main page of the Fuel UI.