So Many Distributions! Information for Selecting One for a Proof of Concept

Transcription

1 So Many Distributions! Information for Selecting One for a Proof of Concept Bruce Basil Mathews Senior Solutions Architect Copyright 2015 Mirantis, Inc. All rights reserved

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 2

3 What Distributions of Openstack Are Included in this Comparison? 3

4 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. 4

5 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 ( ) Rackspace V9: Icehouse ( ) V4.2 (Havana) VirtualBox installation deployed. 5

6 An In Depth Look at each Distribution 6

7 Mirantis 6.0 Openstack Deployment 7

8 Mirantis 6.0 Virtual Machine Deployment Operating System Model (Same for Bare Metal) 3-8 Node Openstack Deployment Oracle VirtualBox Mirantis Fuel Cobbler Docker Containers Version OR Version 6-7 RedHat, Suse or other Linux if desired 8

9 Mirantis Pre-Deployment on VirtualBox Executing launch.sh script installs all the VirtualBox components needed 9

10 The Mirantis 6.0 Openstack Fuel Web Interface 10

11 Fuel: Deployment Name and Mode Selection Selecting the Deployment Mode Defining a New Openstack Environment 11

12 Fuel: Deployment Service Roles and Hypervisor Selecting the Hypervisor Assigning Service Roles to Nodes 12

13 Fuel: Deployment Network and Storage Types Selecting the Backend Storage Type Selecting the Network to Install 13

14 Fuel: Deployment Network and All Other Settings Verifying ALL of the Specific Settings Defining the Specific Network Settings 14

15 Fuel Deployment Premium Services Sahara for Hadoop, Murano for apaas, Ceilometer for Metering, Alerts and Billing 15

16 Fuel: Openstack Deployment in Progress 16

17 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. 17

18 Mirantis 6.0 Openstack In Action 18

19 Mirantis: Horizon, Nova, Neutron, Cinder, etc. Expected Functionality for all Services deployed The Horizon Console 19

20 Mirantis: Openstack Ceph Integration for Cinder AND Swift! 20

21 Mirantis: Murano Premium Project Deployed as Heat Stacks within Horizon Application Catalog within Horizon 21

22 Mirantis: Zabbix Monitoring and Alerts- Experimental Customized Reporting Event Monitoring Dashboard Separate from Horizon 22

23 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. 23

24 Canonical Ubuntu Cloud Openstack Deployment 24

25 Ubuntu Cloud Virtual Machine Deployment Model 25

26 Ubuntu Cloud Bare Metal Deployment Model 26

27 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. 27

28 Ubuntu Cloud-Installer: Text Based Interface Setting the Admin Password Selecting the Install Type 28

29 Ubuntu Cloud-Installer: Off and Running! Installer Success Screen! Installer Status Screen 29

30 Ubuntu Cloud Openstack In Action 30

31 Ubuntu Cloud Openstack: Horizon, Nova, etc. Openstack Functionality works as Expected The Horizon Console 31

32 Ubuntu Cloud: Plus ADDITIONAL Features and Functions within Openstack Load-Balancing Pool Members! Load-Balancing Pools! 32

33 Ubuntu Cloud: ADDITIONAL Features and Functions within Openstack! Firewall-as-a-Service! Load-Balancing Monitoring! 33

34 Ubuntu Cloud: ADDITIONAL Features and Functions Within Openstack VPN IPSec Connection within Horizon! VPN-as-a-Service! 34

35 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. 35

36 HP Helion Openstack Community Edition Deployment 36

37 HP Helion Openstack Community Edition Virtual Deployment Model Operating System HP Helion Download Site 6-Node Virtual Openstack Deployment Version Seed Cloud VM HLinux TripleO 37

38 HP Helion Openstack Community Edition Bare Metal Deployment Model Operating System HP Helion Download Site Seed Cloud VM 6 to 30 Node Bare Metal Openstack Deployment Version HLinux TripleO Ironic 38

39 HP Helion Openstack Commercial Edition Deployment Model Operating System Version HP Helion Download Site Seed Cloud VM HLinux TripleO Ironic 12 to 150 Node Bare Metal Openstack Deployment 39

40 The TripleO Installation Process 1) Deploy the Seed VM The Seed VM contains the minimum services required of OpenStack to be able to provision physical hardware to deploy the Undercloud 2) Deploy the Undercloud The Undercloud server is a single-node OpenStack installation used to deploy, test, manage, and update the Overcloud servers by Cloud Operators 3) Deploy the Overcloud The Overcloud is the functional cloud available to end users for running guest virtual machines and workloads 40

41 Virtual Installation Includes: 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 or installed 41

42 HP Helion Openstack Community Edition Pre- Install Tasks Install Ubuntu or 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 42 At this point, the preparation process is complete

43 HP Helion Openstack Community Edition: Starting the Seed VM NOTE: 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 completed setup seed 43

44 HP Helion Openstack Community Edition: Starting the Undercloud and Overcloud Login to the Seed VM from the Ubuntu Seed Host: # ssh 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

45 HP Helion Openstack Community Edition In Action 45

46 HP Helion Openstack Community Edition: Horizon, Nova, etc. Openstack Functionality works as Expected The Horizon Console 46

47 Overcloud Network Topology Single Flat External Network installed by Default 47

48 Overcloud Stack Deployment 48 As seen from the Undercloud Controller Node

49 What OpenStack Services are included in CE? Juno - 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) 49

50 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-customips.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. 50

51 RDO RedHat Openstack Deployment 51

52 RDO RedHat Single-Node Deployment Model 52

53 RDO RedHat Three-Node Deployment Model 53

54 RedHat Openstack 5.0 Beta Deployment Model 54

55 RedHat Openstack Architecture 55

56 RedHat Openstack Pre-Installation Tasks Nodes must be Registered and Subscribed. 56

57 RedHat Openstack Pre-Installation Tasks Cont d Pre-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: 57

58 Sample of Issues Encountered During PackStack Installation Process Puppet 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: _provision_demo.pp Error: Execution of '/usr/bin/glance -T services -I glance -K 372c2fd db -N image-create --name=cirros --is-public=yes --containerformat=bare --disk-format=qcow2 --copy-from= 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: _mysql.pp Error: mysqladmin -u root password '89c4b1013af04bf8' returned 1 instead of one of [0] RESOLUTION: Deleted Password Manually. 58 There were many more

59 Finally! A Successful PackStack Installation! The Command executed: packstack --answer-file=packstack-answers 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 To use the command line tools you need to source the file. * To access the OpenStack Dashboard browse to Please, find your login credentials stored in the keystonerc_admin in your home directory. * To use Nagios, browse to username: nagiosadmin, password: e bd4 * The installation log file is available at: /var/tmp/packstack/ agauoy/openstack-setup.log * The generated manifests are available at: /var/tmp/packstack/ agauoy/manifests Note: This would print out even if it FAILED 59

60 RDO RedHat Openstack In Action 60

61 RDO RedHat Openstack: Horizon The Horizon Console Deployed by RDO The Horizon Console Expected from the Documentation 61

62 RDO RedHat: Features and Functions Expected from Openstack Didn t Seem to Work! Cinder Volume Delete ERRORS! Object Upload Failed! Swift Containers Failed! Cinder Volume State ERRORS! Cinder Volume Attach Failed! 62

63 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 ( and the RedHat Openstack 5.0 Beta ( are different, containing different versions of the Openstack releases and employing completely different methods for deployment. 63

64 Piston 3.5 Openstack Deployment 64

65 Piston 3.5 Bare Metal Deployment Models 65

66 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 E 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: 66

67 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 67

68 Piston 3.5 Openstack Deployment Projects and Versions The information below was taken directly from the Piston Openstack Data Sheets and defines the versions of Openstack deployed via Cloud Boot: 68

69 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 69

70 Piston 3.5 Openstack In Action 70

71 Piston 3.5 Openstack: Horizon, Nova, etc. Typical Horizon Features and Functions Listed The Horizon Console 71

72 Piston 3.5: What Happened to AirFrame? But the Airframe Site Doesn t Exist! Promotion on their Web Site as of Today 72

73 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. 73

74 Rackspace 4.2 (currently V9) Openstack Deployment 74

75 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. 75

76 Rackspace V9 Components Rackspace Private Cloud version 9 software is based on the OpenStack Icehouse release and includes the following services: Compute (Nova) Dashboard (Horizon) Object Storage (Swift) Block Storage (Cinder) Networking (Neutron) Image Service (Glance) Identity Service (Keystone) Orchestration (Heat) Provision and manage large networks of virtual machines. Provides administrators and users a graphical interface to access, provision, and automate cloud-based resources. Provides redundant, scalable object storage using clusters of standardized servers capable of storing petabytes of data. Provides persistent block level storage devices for use with OpenStack compute instances. Includes OpenStack Block Storage drivers for NetApp and Cinder hosts. 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. 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). Provides a central directory of users, mapped to the OpenStack services they can access. Also integrates with existing OpenLDAP services for user authentication. Allows application developers to describe and automate the deployment of infrastructure via templates. 76

77 Rackspace Virtual Machine Deployment Model 77

78 Rackspace 4.2 Deployment Model Or Learning a Whole Lot about VirtualBox! Defining Network Settings in VirtualBox Defining OVF Settings in VirtualBox Starting the Virtual Machines in VirtualBox 78

79 Rackspace 4.2 Openstack In Action 79

80 Rackspace 4.2 Openstack: Horizon, Nova, etc. Limited Horizon Features and Functions from Havana Listed in 4.2 The Horizon Console Limited Flavors for Compute deployed, etc 80

81 Rackspace 4.2: Plenty of MARKETING in Horizon! 81

82 Rackspace 4.2: Operation Issues Floating IP Assignment ERRORS! User Create ERRORS! Telemetry Disabled! 82

83 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. 83

84 A Question for the Community: How Would You Rate Them? 84

85 In the Final Analysis 1. 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 : 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.) 85

86 Thank You! Your Comments, Disagreements, and Input are Welcome! Bruce Basil Mathews Mirantis Solutions Architect 86 86