Download - So Many Distributions! Information for Selecting One for a ...files.meetup.com/15358852/Comparative-Analysis-Openstack... · • HP Helion Openstack Community Edition: ... • RDO

Copyright © 2015 Mirantis, Inc. All rights reservedwww.mirantis.com

So Many Distributions! Information

for Selecting One for a Proof of

ConceptBruce Basil Mathews

Senior Solutions Architect

© Copyright 2014 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.2

Notes Regarding this Presentation

Before we begin, it is important to understand the nature of the

analysis performed and the information captured:

• Individual Provider Openstack Evaluation Distributions were downloaded and

installed in a pure test and evaluation environment

• Method for Automated Deployment were documented

• The Operational Integrity of the Openstack Distributions were then tested and

documented noting key features and capabilities provided

• An effort was then made to compare and contrast both the Deployment

Methods and the Operational Integrity and features to each other

• Neither Availability nor Scalability characteristics were included as a part of the

comparison


What Distributions of Openstack Are Included

in this Comparison?


What are the Deployment Methods In Summary?

The various Deployment Methodologies for each Openstack Distribution are

provided below:• Mirantis: Employs a Web Based, GUI driven methodology founded on the use of VirtualBox, Fuel, and

Docker. The Bare Metal deployment eliminates the need for VirtualBox and takes advantage of all other

deployment components.

• Canonical: Employs a Text Based, GUI driven methodology founded on the use of Virsh, Juju and

Charms. The use of Virsh is replaced with MaaS in their Bare Metal Deployment.

• HP Helion Openstack Community Edition: Employs a Command Line driven methodology founded on

the use of Virsh and TripleO. The use of Ironic is added for their Bare Metal deployment.

• RDO RedHat: Employs a Command Line driven methodology founded on the use of PackStack, Puppet

and Ruby Gems. Beyond three nodes, the RedHat Openstack 5.0 deployment is performed manually per

node.

• Piston: Does not provide a virtualized Evaluation version of their Distribution and employs a Bootable

USB in conjunction with either an Arista Network switch or a user constructed Cloud Boot host for Bare

Metal Deployment.

• Rackspace: Employs a manual configuration of a VirtualBox virtual machine based on a published OVA

file to form a single-node Openstack environment. Multi-Node deployments are constructed manually.


What Versions of Openstack Gets Deployed?

Once Deployed the following versions of Openstack are installed by

each Provider:

• Mirantis 6.0: Juno (2014.2).

• Canonical Ubuntu Cloud 14.04: Juno (2014.2)

• HP Helion Openstack Community Edition (1.4): Juno (2014.2)

• RDO RedHat 5.0: Juno (2014.2). (Note: RDO is a community-supported OpenStack

distribution that tracks the latest version of OpenStack upstream, beginning with OpenStack Grizzly. Red

Hat Enterprise Linux OpenStack Platform is an enterprise-ready commercially-supported product from

Red Hat)

• Piston 3.5: Icehouse (2014.1.1)

• Rackspace V9: Icehouse (2014.1.1) – V4.2 (Havana) VirtualBox

installation deployed.

http://www.redhat.com/products/enterprise-linux/openstack-platform/


An In Depth Look at each Distribution


Mirantis 6.0 Openstack

Deployment


Mirantis 6.0 Virtual Machine Deployment

Model (Same for Bare Metal)Operating System

Version 12 - 14

OR

Version 6 - 7

Oracle VirtualBox Mirantis

Fuel

Docker

Containers

3-8 Node

Openstack

Deployment

RedHat, Suse or other Linux if desired

Cobbler


Mirantis Pre-Deployment on VirtualBox

Executing launch.sh script installs all the VirtualBox components needed


The Mirantis 6.0 Openstack Fuel Web Interface


Fuel: Deployment – Name and Mode Selection

Defining a New Openstack Environment

Selecting the Deployment Mode


Fuel: Deployment – Service Roles and Hypervisor

Assigning Service Roles to Nodes

Selecting the Hypervisor


Fuel: Deployment – Network and Storage Types

Selecting the Network to Install

Selecting the Backend Storage Type


Fuel: Deployment – Network and All Other Settings

Defining the Specific Network Settings

Verifying ALL of the Specific Settings


Fuel Deployment – Premium Services

Sahara for Hadoop, Murano for aPaaS, Ceilometer for Metering, Alerts and Billing


Fuel: Openstack Deployment in Progress


Zabbix Monitoring Tool

Zabbix is an open source infrastructure monitoring utility that Fuel 5.1 and later can deploy with your OpenStack

environment. See Zabbix implementation for details about how Zabbix is implemented in Mirantis OpenStack.

When planning your Mirantis OpenStack deployment, you must consider the following resource requirements if

you will be deploying Zabbix:

• The Zabbix server must run on its own dedicated node in Mirantis OpenStack 5.1 and 6.0. This server also

stores the Zabbix database.

• A Zabbix agent is installed on each Compute and Storage node in the environment. The agents send all

information to the Zabbix server immediately although some small amount of temporary data may be written

to the local disk for processing.

• Significant network traffic is generated on the Zabbix node as the agents report back to the server; the

agents themselves do not put much load on the network.

• The amount of storage required on the Zabbix node depends on the number of resources being monitored,

the amount of data being gathered for each, and so forth but our internal tests indicate that 30GB of data

storage is adequate for monitoring up to 100 nodes.

• The agents running on the Compute and Storage nodes run periodically; they mainly consume CPU

resources, although they are fairly light-weight processes.

http://docs.mirantis.com/openstack/fuel/fuel-6.0/terminology.html#zabbix-term

http://docs.mirantis.com/openstack/fuel/fuel-6.0/reference-architecture.html#zabbix-arch


Mirantis 6.0 OpenstackIn Action


Mirantis: Horizon, Nova, Neutron, Cinder, etc.

The Horizon Console

Expected Functionality

for all Services

deployed


Mirantis: Openstack Ceph Integration for

Cinder AND Swift!


Mirantis: Murano Premium Project

Application Catalog within Horizon

Deployed as Heat Stacks within

Horizon


Mirantis: Zabbix Monitoring and Alerts- Experimental

Dashboard – Separate from

Horizon

Event Monitoring

Customized Reporting


Mirantis: Observations on Deployment

• The registration and download process are streamlined and are in tune with good customer relations.

• The choice of ISO or IMG distribution for download gives the installer choices against which to apply a deployment model.

• The use of VirtualBox configured by the launch script to spin up a Virtual deployment adds to the ease of deployment in a

virtualized environment.

• The Fuel Web Based Deployment strategy is a huge leap forward for deployment flexibility, choice, and clarity as to what will be

deployed.

• The Network Settings capability and Verification within the Fuel Deployment tool facilitates the ability for the OpenStack

deployment to be more easily integrated with an existing environment.

• The choice of Ceph as an alternative for Cinder and Swift is a key differentiator.

• Inclusion of Premium Projects (Sahara and Murano) are key differentiators.

• Inclusion of alternative Monitoring capabilities such as Zabbix is also a differentiator.

• The feedback during the deployment steps is very helpful and useful to the person installing.

• The choice of platform on which to host the services is also a key differentiator.

• The use of Docker Containers to deploy services to the desired nodes fits very closely with the Openstack direction in Kilo.

• The resulting Openstack implementation appears to be feature rich and operationally sound.


Canonical Ubuntu Cloud Openstack

Deployment


Ubuntu Cloud Virtual Machine Deployment

Model


Ubuntu Cloud Bare Metal Deployment Model


Ubuntu Cloud Pre-Installation Tasks

Execute the following commands as a ‘NON-root’ user:

$ sudo apt-add-repository ppa:juju/stable

$ sudo apt-add-repository ppa:cloud-installer/ppa

$ sudo apt-get update

$ sudo apt-get install cloud-installer

Then, in order to launch the Cloud Installer in a terminal Window, you simply type the

following command as a ‘NON-root’user:

$ sudo cloud-install –s

NOTE: the ‘-s’ switch indicates that Swift should also be installed.


Ubuntu Cloud-Installer: Text Based Interface

Selecting the Install

Type

Setting the Admin

Password


Ubuntu Cloud-Installer: Off and Running!

Installer Status Screen

Installer Success

Screen!


Ubuntu Cloud OpenstackIn Action


Ubuntu Cloud Openstack: Horizon, Nova, etc.

The Horizon Console

Openstack

Functionality works as

Expected


Ubuntu Cloud: Plus ADDITIONAL Features and

Functions within Openstack

Load-Balancing Pools!

Load-Balancing Pool

Members!


Ubuntu Cloud: ADDITIONAL Features and

Functions within Openstack!

Load-Balancing

Monitoring!

Firewall-as-a-Service!


Ubuntu Cloud: ADDITIONAL Features and

Functions Within Openstack

VPN-as-a-Service!

VPN IPSec Connection

within Horizon!


Ubuntu Cloud: Observations on Deployment

• The ability to install via ‘apt-get’ packaged installation without the need to ‘sign up’ or ‘register’ is a significant advantage.

• The limited choice of Operating System (Ubuntu only) may be considered a disadvantage.

• The terminal based installer is somewhat ‘dated’ but seems to be sufficient for the purpose of installing.

• The terminal based deployment is still a leap beyond other deployment methods for ease of use and visibility as to what will be

deployed.

• The additional Network features of LBaaS, FWaaS and VPNaaS are key differentiators.

• The lack of Cinder and Ceilometer are a disadvantage.

• The feedback during the deployment steps is very helpful and useful to the person installing.

• The use of Juju, Charms, and MaaS for deployment fit well with the Open Source community.

• The resulting Openstack implementation appears to be somewhat more feature rich in terms of Networking advanced

capabilities than some other distributions.


HP Helion OpenstackCommunity Edition

Deployment


HP Helion Openstack Community

Edition Virtual Deployment Model

Operating

System

Version 13 - 14

HP Helion

Download

Site

HLinux

6-Node Virtual

Openstack

Deployment

Seed

Cloud

VM

TripleO


HP Helion Openstack Community

Edition Bare Metal Deployment Model

Operating

System

Version 13 - 14

6 to 30 Node

Bare Metal

Openstack

Deployment

HP Helion

Download

Site

Seed

Cloud

VM

HLinux TripleO Ironic


HP Helion Openstack Commercial

Edition Deployment Model

Operating

System

Version 13 - 14

12 to 150 Node

Bare Metal

Openstack

Deployment

HP Helion

Download

Site

Seed

Cloud

VM

HLinux TripleO Ironic


The TripleO Installation Process

1) Deploy the Seed VMThe Seed VM contains the minimum services required of OpenStack

to be able to provision physical hardware to deploy the Undercloud

2) Deploy the UndercloudThe Undercloud server is a single-node OpenStack installation used

to deploy, test, manage, and update the Overcloud servers by Cloud

Operators

3) Deploy the OvercloudThe Overcloud is the functional cloud available to end users for

running guest virtual machines and workloads


Includes:

Virtual Installation

1 Undercloud

1 Overcloud controller

2 Swift nodes (in current release)

1 Overcloud compute node

1 Tenant VM

Installer system requirements (per the documentation):

• At least 48 GB of RAM

• At least 200 GB of available disk space

• Ubuntu 13.10 or 14.04 installed


HP Helion Openstack Community Edition Pre-

Install TasksInstall Ubuntu 13.10 or 14.04 LTS

• Minimal, clean install recommended

Install required packages

$ sudo apt-get install -y libvirt-bin openvswitch-switch python-libvirt qemu-system-x86 qemu-kvm openssh-server

Reboot

Generate a Public Key as root:

# ssh-keygen -t rsa

Log in as root

$ sudo su -

Download and Unpack the Distribution file

$ tar zxvf ~path/Helion_Openstack_Community.tar.gz

This results in creation of a tripleo/ directory in the root’s home directory

At this point, the preparation process is complete


HP Helion Openstack Community Edition:

Starting the Seed VMNOTE: All STEPS MUST BE REPEATED FROM THIS POINT FORWARD EACH TIME THE PHYSICAL

MACHINE HOSTING THE SEED IS REBOOTED

Use the following command to start the seed VM

# HP_VM_MODE=y bash -x ~root/tripleo/tripleo-incubator/scripts/hp_ced_start_seed.sh

This process can take 10 minutes or more

• The first time this is run, it will check to ensure all of the required packages are installed. If you are

prompted, accept all package installations

• You will see a lot of logging messages while the script runs

If the Seed VM start is successful, a message is displayed

Wed Aug 27 11:25:10 UTC 2014 --- completed setup seed



Starting the Undercloud and OvercloudLogin to the Seed VM from the Ubuntu Seed Host:

# ssh 192.0.2.1

On the Seed VM, launch the install script

root@hLinux:~# bash -x ~root/tripleo/tripleo-incubator/scripts/hp_ced_installer.sh

v1.3 release includes informational comments in the script

- “this could take up to 15 or more minutes”

- “waiting for undercloud to stabililze”

- “waiting for the overcloud stack to be ready”

- “this could take up to 30 or more minutes”

- “this is the final step – expect to wait eight or more minutes”

Success = “HP - completed -Wed Aug 27 16:20:02 UTC 2014”


HP Helion OpenstackCommunity Edition

In Action



Horizon, Nova, etc.

The Horizon Console

Openstack

Functionality works as

Expected


Single Flat External Network installed by Default

Overcloud Network Topology


Overcloud Stack Deployment

As seen from the Undercloud Controller Node


What OpenStack Services are included in CE?

• Compute (Nova)

• Networking (Neutron)

• Identity (Keystone)

• Object Storage (Mini-Swift)

• Block Storage (Cinder)

• Image Service (Glance)

• Dashboard (Horizon)

• Orchestration (Heat)

• Installation (TripleO)

• Bare Metal (Ironic)

Juno -


HP Helion OpenStack: Observations on Deployment

• The limited choice of Operating System (Ubuntu only) on which to install the Seed Host as a Virtual Machine (the only way the

Seed host can be deployed) may be considered a disadvantage.

• The command line based installation scripts seem somewhat limited, but sufficient for the purpose of installing.

• The need to edit environment variables to control deployment settings contained in the files kvm-custom-ips.json or esx-custom-

ips.json dependent on the type of hypervisor to deploy, seems a bit cumbersome. There are more than 100 variables to consider.

• The use of a file (baremetal.csv) on the Seed Host to define the control nodes of the OpenStack cluster doesn’t allow for specific

service roles to be assigned to specific Virtual or Bare Metal nodes which may be considered a disadvantage.

• The use of TripleO and Ironic as deployment tools is in line with the direction of Kilo and fits well with the OpenStack community.

• The inclusion of Ceilometer is a key differentiator.

• The hosting of the Seed, Undercloud and Overcloud on a unique version of Linux (Hlinux, a Debian derivative developed by HP)

may reduce the potential for wider adoption.

• The resulting Openstack implementation appears to be reasonably feature rich and operationally sound.


RDO RedHat Openstack

Deployment


RDO RedHat Single-Node Deployment Model


RDO RedHat Three-Node Deployment Model


RedHat Openstack 5.0 Beta Deployment Model


RedHat Openstack Architecture


RedHat Openstack Pre-Installation TasksNodes must be Registered and Subscribed.


RedHat Openstack Pre-Installation Tasks – Cont’dPre-PackStack Installation Steps.

From the RDO Quickstart Guide, the installation process takes three simple steps:

•Install the required Software Repositories•Install the Packstack Installer•Run Packstack to Install Openstack

If any of these fail, the consumer is directed as follows:


Sample of Issues Encountered During

PackStack Installation ProcessPuppet Automatic Installation Failure

– ERROR : Failed to run remote script, stdout: no package provides puppet

– Loaded plugins: langpacks, product-id, subscription-manager

– RESOLUTION: Puppet had to be installed manually to resolve this issue.

Glance DEMO Image Upload Failure

– ERROR : Error appeared during Puppet run: 172.16.200.121_provision_demo.pp

– Error: Execution of '/usr/bin/glance -T services -I glance -K 372c2fd6986448db -N http://172.16.200.121:35357/v2.0/ image-create --name=cirros --is-public=Yes --container-

format=bare --disk-format=qcow2 --copy-from=http://download.cirros-cloud.net/0.3.1/cirros-0.3.1-x86_64-disk.img' returned 1: 400 Bad Request

– RESOLUTION: Add provision_demo=n to the Packstack Command Line and Upload the Image Post Installation via Horizon.

MySQL Password Reset Fails

– ERROR : Error appeared during Puppet run: 172.16.200.121_mysql.pp

– Error: mysqladmin -u root password '89c4b1013af04bf8' returned 1 instead of one of [0]

– RESOLUTION: Deleted Password Manually.

There were many more…


Finally! A Successful PackStack Installation!The Command executed:

packstack --answer-file=packstack-answers-20140927-211511.txt

The Conclusion of the Installation Process:

**** Installation completed successfully ******

Additional information:

* Time synchronization installation was skipped. Please note that unsynchronized time on server instances might be problem for some

OpenStack components.

* Did not create a cinder volume group, one already existed

* File /root/keystonerc_admin has been created on OpenStack client host 172.16.200.121. To use the command line tools you need to

source the file.

* To access the OpenStack Dashboard browse to http://172.16.200.121/dashboard .

Please, find your login credentials stored in the keystonerc_admin in your home directory.

* To use Nagios, browse to http://172.16.200.121/nagios username: nagiosadmin, password: e617591991474bd4

* The installation log file is available at: /var/tmp/packstack/20140927-214429-AGAUoy/openstack-setup.log

* The generated manifests are available at: /var/tmp/packstack/20140927-214429-AGAUoy/manifests

Note: This would print out even if it FAILED…


RDO RedHat OpenstackIn Action


RDO RedHat Openstack: Horizon

The Horizon Console

Expected from the

Documentation

The Horizon Console

Deployed by RDO


RDO RedHat: Features and Functions Expected

from Openstack Didn’t Seem to Work!

Swift Containers

Failed!

Object Upload Failed!

Cinder Volume Attach Failed!Cinder Volume State ERRORS!

Cinder Volume Delete

ERRORS!


RDO RedHat: Observations on Deployment

• The Packstack Installation method seems bug ridden and error prone with little Negative Path Correction capability, even for an

advanced user of the RedHat Operating System.

• Packstack error resolution requires intimate knowledge of Puppet, MySQL and MariaDB.

• The version of Juno produced by the Packstack installation seems bug ridden and would require an intimate knowledge of

Openstack services (Nova, Cinder, Swift, Keystone, etc.) to resolve.

• The automated installation only allows for a three-node Openstack cluster to be deployed.

• For implementations suitable for a Production environment it is recommended to perform a more elaborate manual installation.

• Anything above a three node implementation MUST be done manually.

• Before installing RDO OpenStack, you would have to first install and configure the RedHat 7 Operating System environment and

achieve full ‘registration’ and ‘subscription’ of the node with RedHat.

• The repositories containing the RDO version (www.fedoraproject.org) and the RedHat Openstack 5.0 Beta (www.cdn.redhat.com)

are different, containing different versions of the Openstack releases and employing completely different methods for

deployment.

http://www.fedoraproject.org/


Piston 3.5 OpenstackDeployment


Piston 3.5 Bare Metal Deployment Models


Piston 3.5 Hardware Configuration Information

Each host in the configuration is configured identically with the

exception of the Cloud Boot host in the Modular configuration.

Three possible options are provided:

HP DL360 - Dual Intel® E5-2600v2 or E5-2600 Series processors

Silicon Mechanics (RackForm iServ R354.v4) - Dual Socket

Intel® Xeon® E5-2600v2 C602 Chipset

Dell R710 – Dual Quad-core or six-core Intel® Xeon®

processor 5500 and 5600 series

The Cloud Boot host configuration requires the following

components:

The Cloud Boot Network configuration requires the following

components:


Piston 3.5 Cloud.conf Configuration Information

Between 50 and 75 parameters must be defined in the cloud.conf file prior to beginning the

installation. A cloud.conf.sample file is provided as a base. The areas for which the parameters must

be defined include, but are not limited to:

• Network Parameters

• Upstream Server Configuration Parameters

• Authentication Parameters

• Servers Configuration Parameters

• Storage Configuration Parameters


Piston 3.5 Openstack Deployment Projects and

VersionsThe information below was taken directly from the Piston Openstack Data Sheets and defines the

versions of Openstack deployed via Cloud Boot:


Piston 3.5 Openstack Key Additional Features

and Capabilities

The information below was taken directly from the Piston

Openstack Web Site and defines the items that Piston believes

are their key differentiators:

• Moxie RTE – High Availability Engine

• Virtual Memory Streaming

• Iocane-Micro OS

• Intel Trusted Execution Technology Support


Piston 3.5 OpenstackIn Action


Piston 3.5 Openstack: Horizon, Nova, etc.

The Horizon Console

Typical Horizon

Features and

Functions Listed


Piston 3.5: What Happened to ‘AirFrame’?

Promotion on their

Web Site as of

Today…

But the ‘Airframe’ Site

Doesn’t Exist!


Piston 3.5: Observations during Deployment• The ‘boot from network switch’ or ‘boot from bare metal server’ approach to installation seems reasonable enough, but it may limit the size of the

implementable cloud even though they indicate that their base configuration could be expanded to support as many as 250 compute nodes.

• The version of Icehouse Openstack services (Nova, Cinder, Swift, Keystone, etc.) seem to be fairly current, but there is no mention of Juno in any of

their documentation.

• The Moxie RTE methodology for providing High Availability to the configured cloud implies that all nodes in the ‘election pool’ must be configured to

support all services.

• The Unified deployment approach doesn’t seem to allow for many choices in configuration.

• The Modular approach to deployment seems to allow for more choice, but seems to require a great deal more manual configuration.

• Based on the information provided by Shawn Madden in the Quick-Start deployment video, the best and only place to look for issues during

deployment is in the Syslog file. Syslog must be configured manually before starting the deployment procedure. There is a Boot Web Console, but the

information and errors displayed are transient.

• Evidently, ‘storage ratios’ defined in the configuration file MUST be ‘accurate’ to the volume of storage available in each node. If it is not entered

accurately to the scale of storage available for each category of storage defined, one category may begin to devour the other.

• The same issues and concerns could be raised about the Piston Operating System (Iocane Micro-OS™) as with HLinux for HP Helion OpenStack.


Rackspace 4.2 (currently V9)

OpenstackDeployment


Rackspace Private Cloud V9 is Deployed

Differently

• Rackspace Private Cloud (RPC) v9 Software uses a combination of Ansible and Linux Containers

(LXC) to install and manage OpenStack Icehouse.

• Rackspace no longer supports a Virtual Machine installation using VirtualBox for investigative

purposes.


Compute (Nova) Provision and manage large networks of virtual machines.

Dashboard (Horizon)Provides administrators and users a graphical interface to access,

provision, and automate cloud-based resources.

Object Storage (Swift)Provides redundant, scalable object storage using clusters of

standardized servers capable of storing petabytes of data.

Block Storage (Cinder)

Provides persistent block level storage devices for use with

OpenStack compute instances. Includes OpenStack Block

Storage drivers for NetApp and Cinder hosts.

Networking (Neutron)

Pluggable, scalable, API-driven network and IP management.

Manage flat and VLAN provider networks; flat, VLAN, and VXLAN

overlay (tenant) networks; and layer-3 agents for routing, NAT,

and floating IP addresses.

Image Service (Glance)

Provides discovery, registration, and delivery services for disk and

server images. Supports a variety of common image formats

(Raw, AMI, VHD, VDI, VMDK, OVF, qcow2).

Identity Service (Keystone)

Provides a central directory of users, mapped to the OpenStack

services they can access. Also integrates with existing OpenLDAP

services for user authentication.

Orchestration (Heat)Allows application developers to describe and automate the

deployment of infrastructure via templates.

Rackspace Private Cloud version 9 software is based on the OpenStack Icehouse release and includes the following services:

Rackspace V9 Components


Rackspace Virtual Machine Deployment Model


Rackspace 4.2 Deployment Model –

Or Learning a Whole Lot about VirtualBox!

Defining OVF Settings

in VirtualBox…

Defining Network

Settings in

VirtualBox…

Starting the Virtual

Machines in

VirtualBox…


Rackspace 4.2 OpenstackIn Action


Rackspace 4.2 Openstack: Horizon, Nova, etc.

The Horizon Console

Limited Horizon

Features and

Functions from Havana

Listed in 4.2

Limited Flavors for

Compute deployed,

etc…


Rackspace 4.2: Plenty of MARKETING in

Horizon!


Rackspace 4.2: Operation Issues

Telemetry Disabled!

User Create ERRORS!

Floating IP

Assignment ERRORS!


Rackspace 4.2: Observations During

Deployment

• The registration and download process are reasonably streamlined and in tune with good customer relations.

• The use of an OVA file for distribution download limits the choices for installation to either ESX or VirtualBox Virtual Machines.

• The additional manual VirtualBox configuration steps are not very well documented and are prone to errors affecting the usability

of the deployed Openstack distribution for testing and evaluation.

• Deployment on a single Virtual Machine causes the test environment to behave sluggishly and limits usability for test and

evaluation.

• The lack of Neutron Network functions in 4.2 and limitations of the Nova-Network implementation result in reduced usability for

test and evaluation.

• The lack of any type of deployed Object Storage in 4.2 could be considered a disadvantage.

• The feedback during the deployment process is almost non-existent until the end, when a successful installation displays the IP

address and URL of the Horizon Interface.

• The resulting Havana Openstack implementation appears to be somewhat buggy and behaves sluggishly from a performance

perspective.


A Question for the Community:

How Would You Rate Them?


In the Final Analysis1. Mirantis 6.0: The Web-Based, GUI Driven Deployment is rather compelling. The use of Fuel and Docker resonates well with the

Openstack Community. The ability to integrate into an existing customer Network is heightened by the choices definable and

Network Verification function built into the Fuel Deployment tool. The choice of Operating System is compelling to IT

organizations who must certify the environment. The deployed Juno version seems very stable. The choice of Ceph as an

alternative for Cinder and Swift is a key differentiator.

2. Canonical Ubuntu Cloud 14.0.4: The terminal based installer, though a bit dated, is more user friendly than command line

installations. The use of Juju, Charms, and MaaS for deployment fit well with the Open Source community. The resulting

Openstack implementation appears to provide more features in terms of Networking capabilities. The additional Network

features of LBaaS, FWaaS and VPNaaS key differentiators! The lack of Cinder and Ceilometer deployments are a disadvantage!

3. HP Helion Openstack Community Edition 1.4: The consistency between deployment methodology for Virtual, Bare Metal and

Commercial is a plus. The deployed version of OpenStack features and capabilities deployed seem fully functional. The lack of

Ceph integration and enhanced Neutron networking features is a disadvantage. The command line driven deployment method is

much less user friendly. The use of TripleO and Ironic for deployment resonate well with the Openstack community.

4. RDO RedHat Openstack 5.0: The Packstack Installation method seems bug ridden and error prone with little Negative Path

Correction capability. The version of Icehouse produced by the Packstack installation seems less rock solid than expected.

Anything above a three node implementation MUST be done manually. OpenStack versions are different between RDO and

RedHat commercial offering.

5. Piston 3.5: The ‘boot from network switch’ or ‘boot from bare metal server’ approach may limit the size of the deployable

Openstack environment. All nodes in the ‘election pool’ must be configured to support all services to make Moxie RTE work for

High Availability. Piston announced the availability of a free evaluation version called AirFrame and failed to deliver.

6. Rackspace 4.2: The manual VirtualBox configuration steps are not very well documented. Limitations of the Nova-Network

implementation are a problem. The lack of any type of deployed Object Storage is a disadvantage.The older Havana Openstack

implementation appears to be bug ridden and sluggish. These issues may have been addressed in V9 (Icehouse.)


Thank You!

Your Comments, Disagreements, and Input

are Welcome!

Bruce Basil Mathews – Mirantis Solutions Architect

[email protected]

86

mailto:[email protected]