Deploying OpenStack with Ubuntu Autopilot and … · Web viewDeploying OpenStack with Ubuntu Autopilot and MAAS Taylor Chien 12-14-2016 Contents Introduction2 What is the purpose

Deploying OpenStack with Ubuntu Autopilot and MAAS

Taylor Chien12-14-2016

Taylor Chien Deploying OpenStack with Ubuntu Autopilot and MAAS 12/16/2016Capstone Project NCS 495

ContentsIntroduction.................................................................................................................................................2

What is the purpose of this research?.....................................................................................................2

Why did this research need to be done?.................................................................................................2

How was this research done?..................................................................................................................2

Who assisted in this research?................................................................................................................2

MAAS Overview...........................................................................................................................................2

Juju..........................................................................................................................................................3

Ubuntu OpenStack Overview......................................................................................................................3

Modules...................................................................................................................................................4

Autopilot..................................................................................................................................................4

Installation Process......................................................................................................................................4

Step 1: Hardware Setup...........................................................................................................................4

Dell IPMI..............................................................................................................................................5

Virtualization Extensions and Boot Options.........................................................................................5

Ethernet Cabling..................................................................................................................................5

Ubuntu Server Installation...................................................................................................................5

Step 2: Add Required Repositories..........................................................................................................5

Step 3: Install MAAS................................................................................................................................5

Step 4: Configure the MAAS Cluster........................................................................................................5

Differences...........................................................................................................................................5

Frozen Artifact IP Addresses (16.04 LTS, MAAS 2.0)............................................................................5

Step 5: Register your hardware with MAAS.............................................................................................6

General Differences.............................................................................................................................6

Issues with Commissioning and Deleting (14.04 LTS, MAAS 1.9).........................................................6

Issues with mDNS (16.04 LTS, MAAS 2.0)............................................................................................6

Curtin and Deployment Failures (16.04 LTS, MAAS 2.0)......................................................................7

Step 6: Launch OpenStack Autopilot (Ubuntu 16.04)..............................................................................7

Using Actual OpenStack...............................................................................................................................7

Networking..............................................................................................................................................7

Appendix I: OpenStack Services Chart.........................................................................................................8

Appendix II: Ethernet Diagram....................................................................................................................9

1


Appendix III:..............................................................................................................................................10

IntroductionThis paper will cover the basics of what OpenStack, Ubuntu Autopilot, and MAAS are, and how they all work together to deploy the virtual environment.

What is the purpose of this research?Virtualization is the future of the datacenter, and having a grasp on the process of deploying different hypervisors will be critical. OpenStack is a modular and flexible system with many options for deployment and management, and its use is growing rapidly. Per OpenStack1, 55% of OpenStack deployments are running on Ubuntu, most likely because of Ubuntu Autopilot, a simplified solution for deploying OpenStack, developed by Ubuntu.

Why did this research need to be done?OpenStack is a fast growing and extremely popular hypervisor, and developing an understanding of how one of the most popular hypervisor solutions in the world works is critical. OpenStack is unique since it offers options in deployment, and those different options can affect deployment. Also, there are many, many different versions of OpenStack, and each is incompatible with the others in the line. Ubuntu offers a central, known system for deploying OpenStack, and it makes an excellent option to discover what the system can do.

How was this research done?This paper will be mostly theoretical, with some practical elements pulled from active OpenStack deployments I have worked with. Unfortunately, due to a lack of communication between certain parties that oversaw my capstone, I was not able to do much of my practical research in time for the end of the semester. Due to both lack of space and access, there are multiple sections that I was not able to complete on my own, and had to refer to external sources for.

Who assisted in this research?I must thank Professor Joshua White for allowing me to access to an active OpenStack deployment, and the NCS Club for providing me with last-minute hardware needed to perform the actual hardware tests as needed.

MAAS OverviewMAAS, or Metal as a Service, is the chosen deployment system for Ubuntu. MAAS uses PXE to deploy images on remote machines and manage them together in a single environment. MAAS uses Juju, another Ubuntu service, to automatically create “Charms”, or pre-made software packages, for pre-deployed images which can then be installed on the hardware managed by MAAS. MAAS can also be used to deploy CentOS/RHEL/Scientific Linux, SUSE/openSUSE and Windows, although it can only deploy the image and manage the power state, not install or manage software.

MAAS is split into two main components; Region controllers and Rack controllers. Region controllers oversee the node management, user management, network interactions, and interaction between

1 http://superuser.openstack.org/articles/openstack-users-share-how-their-deployments-stack-up

2


different Racks. Most standard deployments have a central Region controller or several Region controllers in high availability. These operate as the backbone between different racks and different sections of the network.

Rack controllers, on the other hand, are directly in control of their nodes, deploying the operating systems and managing their images and power states. Using their own DHCP and PXE (Pre-eXecution Environment) services, the Rack controller is meant to take care of deploying its own local machines, which allows for easy re-deployment, upgradeability, and some scalability options when it comes to running Ubuntu.

In the environment, I was using both the Region and Rack controllers on the same machine. The only change to a multi-server MAAS environment is that there is no need to set up a link between the Region and Rack controllers.

Also, the MAAS version was upgraded on the release of 16.04 to MAAS 2.0, which is still in active development, and has a completely new menu and integration options.

MAAS runs on top of an Apache web server and integrates with its backend through that. By default, HTTPS is completely disabled, since the completely default install of Apache has no HTTPS module or certificate enabled.

JujuJuju is Ubuntu’s system that deploys software on MAAS deployed images. Juju installs software using a small Docker-like system to deploy Charms to the systems that it manages. Since Juju is Ubuntu only, it cannot deploy software to the non-Ubuntu options that MAAS has. Juju can be used to deploy entire active systems, with pre-configured services all ready. OpenStack is one of those services, but Juju charms include web servers, databases, monitoring, and data analytics applications.

Along with the release of MAAS 2.0, Juju was upgraded to version 2, but the Juju release is behind at the time of writing. Since MAAS 2.0 is only compatible with Juju, that leaves a lot of bugs from the integration of the two in-development pieces of software. Also, as I discovered late in the development process, Autopilot is based on the old version of Juju, and has not yet been rewritten for Juju 2 and MAAS 2.0.

Ubuntu OpenStack OverviewOpenStack is a scalable hypervisor solution like Amazon AWS or Digitalocean. OpenStack is run through eleven services that can be reprogrammed, removed, and changed by the end user to make a completely customized OpenStack deployment that fits the user’s needs. Instead of being a full operating system like XenServer or Proxmox, OpenStack is a set of software installed on top of the operating system, and can even span multiple operating systems.

The main component of any OpenStack deployment is OpenStack itself. There are many versions of OpenStack available, but the most recent version that Ubuntu Autopilot uses for version 16.04 uses is OpenStack Icehouse, which will remain with Ubuntu 16.04 LTS for its full five years. Icehouse is technically End of Life per OpenStack themselves, but Ubuntu will continue to support the distribution, making this Ubuntu OpenStack instead of OpenStack. OpenStack is also completely open source, which is what enables Ubuntu to fork their own branch of OpenStack Icehouse.

3


For this paper, I will only be focusing on Ubuntu OpenStack, and OpenStack Icehouse, which is what Autopilot will be deploying. I will not be talking about other OpenStack releases or comparing others, since short of manual installation, Icehouse is currently the most recent version of OpenStack available with Ubuntu.

ProcessWhen OpenStack is deployed, it has three main server types; computation, storage, and controller. These are the backbone of the deployment process. There are alternative types of nodes available, but they are outside of the scope of this article and will only be mentioned.

ControllerThe controller manages all network operations for the cluster, like routing between OpenStack networks, performing NAT for the OpenStack internal routers, managing security groups, and doing network creation and deletion for different virtual and physical servers. These servers also manage security and logins.

StorageThe storage server’s task is obvious: to store the data of the cluster. This is used for both object and block storage.

ComputeThis node type is used for running VMs and Containers on an OpenStack cluster. They manage the VMs using Nova or the chosen hypervisors.

Management ControllerThis is an alternative mode for a normal controller node which oversees other controller nodes. These are usually only found in extremely high availability networks where no downtime is acceptable. The management controller performs like a regular Controller, but its primary task is to run the Horizon web GUI for the cluster and push that information to the other controllers.

NetworkThe network nodes are only necessary when the volume of traffic from VMs exceeds the carrying capacity of the controller nodes. Dedicated network nodes can be deployed to help extremely large OpenStack deployments with high data transfer scenarios, where VMs are transferring terabytes of data constantly.

OpenStack Deployment ModelsThere are three different types of deployment models for OpenStack, each of which has its own advantages and disadvantages.

1. OpenStack on a single node with all services running on one node with no high availability2. OpenStack on multiple nodes (usually two or three), with no high availability, but distributed

services3. OpenStack on three or more nodes with high availability enabled, allowing expansion and

deployment of more nodes.

Ubuntu Autopilot is built to make a high availability cluster of OpenStack servers. Therefore, Autopilot requires a minimum of five servers to operate in true high availability mode. These servers are, in order:

4


1. The MAAS server, managing deployments2. The Autopilot server, which manages the MAAS nodes separately3. The Controller node4. The Compute node5. The Storage node

Autopilot will also automatically deploy different types of nodes depending on what is needed. If networking is throttled, then another Controller will be deployed. If there are not enough CPU cores, a new computation node will be deployed. Autopilot will then remember what the different deployed nodes are and use MAAS to control their power states and deployment and upgrade options.

ModulesOpenStack is made up of eleven core elements which make up the OpenStack cluster environment. Each module is responsible for a different service, which allows for deployments of only the bare minimum of services. Usually those core services are Horizon, Nova, Neutron, and Swift, which are the absolute minimum for operation. In the Appendix is a chart taken from OpenStack which describes all the available modules and what their roles are. For this deployment, only the core modules will be covered in any depth, since this is about the actual setup of the OpenStack cluster using Autopilot, not OpenStack itself.

AutopilotAutopilot is Ubuntu’s solution for deploying OpenStack using MAAS. Autopilot is pointed at a deployed server from MAAS and uses that system as a Landscape controller, which is Ubuntu’s server management web service. That server then acts as a controller for all the deployed servers that have been designated as OpenStack.

Autopilot is only free for up to ten servers though. At ten, Autopilot requires the hefty price of $750 per socket. This is useful for situations like education and testing, where an entire ecosystem will be set up and torn down within a year.

Installation ProcessThe installation process on Ubuntu’s website is very straightforward and is presented as the “Get OpenStack Autopilot2” option. There are sixteen steps listed, each with multiple parts. However, due to numerous issues I will list later, neither of my attempts could make it past step five.

Step 1: Hardware SetupThe hardware that I used for this project consisted of six Dell 860 Servers, with two Dell Dimension 5150s for testing, a Cisco 2811 Router and a Cisco 2960X Switch.

2 https://www.ubuntu.com/download/cloud

5


Server Name Hardware Purpose

CPU Cores

RAM (GB)

HDD Qty.

HDD (GB) Ethernet

Totals 16 28 152811 Cisco 2821 Router - - - - 12960X Cisco 2960X Switch - - - - -24enterprise Dell PowerEdge 860 MAAS Region/Rack Controller 2 4 2 750 2yorktown Dell PowerEdge 860 MAAS Node 2 4 2 750 2saratoga Dell PowerEdge 860 MAAS Node (Constant Failure) 2 4 2 750 2oriskany Dell PowerEdge 860 MAAS Node 2 4 2 750 2essex Dell PowerEdge 860 MAAS Node 2 4 2 750 2wasp Dell PowerEdge 860 MAAS Node 2 4 2 750 2dim5150-1 Dell Dimension 5150 MAAS Test Node 2 2 1 160 1dim5150-2 Dell Dimension 5150 MAAS Test Node 2 2 1 160 1

Dell IPMIEach of the Dell 860 servers has an Intelligent Platform Management Interface (IPMI) to which MAAS must have access to remotely power on each server. These IPMI interfaces act as a virtual interface on the first Ethernet interface, and are configured in one of the BIOS menus. I gave all of the servers’ IPMI interfaces a static IP address in order to easily tell which server was which when the MAAS process began.

Virtualization Extensions and Boot OptionsIn the BIOS, there are several options that I had to change. First, I had to enable PXE boot on the first interface through the “Integrated Devices” menu. Then, in the main menu, I had to change the second SATA device to enabled, then completely disable boot from the Hard Drives, making sure that only the Network Boot option is enabled. In CPU options, I checked that the virtualizations were enabled for all servers.

Ethernet CablingAnother major component of this build was the cabling and configuration of the network interfaces. In the Appendix is a diagram of what was plugged into the switch and how it was all connected. All switch ports were configured as access ports with “portfast” enabled. Also, to stop issues with DHCP timeouts on the Router’s outside interface, I created a separate VLAN on the switch so that while I was configuring the router, the interface wasn’t constantly timing out its DHCP requests.

Ubuntu Server InstallationThe process for installing Ubuntu has been well documented by multiple sources, so I won’t be going through this in any detail. The only server that needs the installation process done to it is the main MAAS server, which in this case is named “Enterprise”.

Step 2: Add Required RepositoriesHere, there are three simple lines that can be copied to the command line of the server. This installs the requirements for MAAS and the MAAS PPA repository.

6


Step 3: Install MAASNow comes the process of installing MAAS, which is relatively straightforward, since it is just “apt install maas”, then setting an administrator username and password.

Step 4: Configure the MAAS ClusterNote: This is the point where I have two different methods, because I attempted this twice, once with Ubuntu 16.04 LTS and Ubuntu 14.04 LTS. The autopilot guide is meant for Ubuntu 14.04, but Ubuntu 16.04 has a different process after this.

DifferencesMAAS 2.0 can contain multiple static and dynamic ranges for different purposes, while MAAS 1.9 can only contain one range of each. In MAAS 2.0, these options are in the “Networking” tab and are configured per subnet instead of per interface. In MAAS 2.0, there is no “Clusters” tab. Instead, the management of DHCP and DNS is set by subnet, under Networking. Each subnet must be granted their own separate permissions for DNS and DHCP management.

Frozen Artifact IP Addresses (16.04 LTS, MAAS 2.0)When a machine is deleted in MAAS 2.0, the IP address is not released from the dynamic pool properly, and remains as a “Device IP Address”, which in MAAS world, is a machine that is not managed by MAAS and cannot be controlled. The IP address is frozen in place, and will not change no matter what happens. I found no way of reversing this, so the frozen IP Addresses stayed in place for the entirety of testing.

Misconfigured MAAS URLWhen I first set up the MAAS server, I did it on an active network with a different IP range. When I moved to a new IP address in a new range, the MAAS scripts still contained a link to this old IP Address, causing several of the scripts to time out attempting to access and IP that no longer existed.

The fix for this was changing the region controller configuration and changing that static IP back to the current IP, which immediately fixed the issues.

Step 5: Register your hardware with MAASAll this step requires is that all servers that are going to be part of the MAAS cluster are set to PXE boot, then turned on.

For Ubuntu 16.04, the differences are all in the menus. Ubuntu 16.04 uses MAAS 2.0, while Ubuntu 14.04 uses MAAS 1.9. MAAS 2.0 has significant differences from 1.9, so much so that there are separate help pages for this version.

This is when the servers are commissioned and then deployed. Commissioning a server records all of the information about the server and makes it available for modification. Deployment is pushing out that configuration to the server, along with the operating system and the kernel.

General DifferencesSince MAAS 2.0 is still in development, there were issues that I found early on. The automatic management scripts have some massive issues when dealing with the Dell IPMI on the 860 servers, as we will see later on.

7


Issues with Commissioning and Deleting (14.04 LTS, MAAS 1.9)For an unknown reason, in Ubuntu 14.04 all of the devices would be unable to commission due to a 500 error when reporting the results to the server. When looking at the screen, the reason was obviously due to a malformed URL, but nowhere was I able to find what the URL should be. After searching for a while, I decided to delete the servers from MAAS and try again with an HWE kernel.

However, this showed another issue. The servers were unable to be deleted due to not existing in the metadata of the server. The only possibilities are a damaged or misconfigured daily Ephemeral build (the deployment operating system image of Ubuntu for MAAS), or an incompatible patch from MAAS for 1.9. I was unable to move forwards of backwards in time to complete this report unfortunately, so the issue is still unresolved. I was unable to continue with the Ubuntu 14.04 Autopilot installation from here, so this is where the Ubuntu 14.04 method ends.

Issues with mDNS (16.04 LTS, MAAS 2.0)Dell IPMI interfaces automatically send out the hostname “BMC dhcp” for some reason, even when manually set. MAAS 2.0 places this name into the zone file with the space, which creates an “invalid syntax” error when bind checks the file, which unloads the zone. I discovered this early on when the DNS services kept crashing repeatedly. Even setting the names of the IPMI interfaces did not change the mDNS record.

Also, the mDNS service did not recognize when a machine was deleted. After much frustration with being unable to use the DNS service, I discovered that there were five or six entries from the same machines that had been deleted after failing to commission.

The only way that I find that fixes both issues is to manually delete the lines in MAAS’s zone file. This can be a bit of a pain, since MAAS will eventually regenerate them over time as the servers turn off and on and go in and out of commissioning and deployed.

Curtin and Deployment Failures (16.04 LTS, MAAS 2.0)When the servers were being deployed from MAAS in Ubuntu 16.04, there were issues with a program called Curtin, which does the partitioning of hard drives. On all servers but one, Curtin deployed successfully on a single disk. However, when the deployment method was switched to a RAID configuration, Curtain attempted to write to “md01”, while the device that was created was “md0”. This is a known bug with Curtin and MAAS 2.0, and is in the process of being patched.

Step 6: Launch OpenStack Autopilot (Ubuntu 16.04)This is the point where I discovered that Ubuntu 16.04 and MAAS 2.0 do not have support for Ubuntu Autopilot yet. Because Juju 2 is still in testing, and MAAS 2.0 only supports Juju 2, Autopilot will not work yet.

However, I did try the manual method, which uses the Conjure-Up service for manual Juju charm creation. This failed miserably, as expected, since the Conjure-Up method has a severe lack of usability and is somewhat broken when integrating with MAAS 2.0.

Using Actual OpenStackDue to the complete failure of deploying my own OpenStack cluster, and the fact that I had access to an OpenStack Newton release cluster, I decided to try to use it. However, every time I attempted to use the

8


environment to load a VM, I would be unable to access the VM via SSH or console. Professor White, who gave me access, said that he had never seen my issue before. Due to this, I was unable to test the VMs and how some of the special OpenStack Orchestration and Deployment features worked.

Also, due to its heavily customized appearance and significant changes from the Icehouse release to the Newton release, the observations I will be making are more about using OpenStack and what features are different from other Hypervisors.

The version of OpenStack I was using was also not an Ubuntu Autopilot system. It was instead made by Mirantis, who support multiple operating systems with their deployment system, which is similar to MAAS and Autopilot combined into one service.

NetworkingThe networking system is very robust and visual, with a map of what you have that is connected to what. However, this comes with its own drawbacks, since the map can be highly confusing. For example, a simple setup with only one VM, a router, and an Open-Vswitch interface on each, the map includes four elements, each marked with a UUID instead of an IP or a name.

VM ControlThe VM creation process is very simple and very like the VM type selection that Amazon EC2 uses, at least on the system that I was using. There were live statistics, the boot and kernel logs, security group management, and more configuration options. This allowed total control over a system with minimum button pushing. Some features, like the Floating IP options and the boot options, were hidden in submenus, and others, like the network options, were in a completely separate section, but other than that, the overall experience was relatively straightforward once all of the buttons were found.

Conclusion for the Newton clusterWhile I was easily able to navigate the menus, create VMs, perform networking tasks, and check on my usage statistics, I did have issues with buried menus and hidden options. I was not able to get a full administrative experience of OpenStack, but that seems to be my curse with OpenStack.

Comparison to other HypervisorsThere are a lot of Hypervisors out there that offer different options and more smooth deployment than OpenStack, and I have used quite a few of them, so I feel a need to compare what I used to what I tried to build in this project.

ProxMoxOpenStack and ProxMox have a lot in common, like a very intuitive web GUI and advanced yet intuitive VM creation and usage. However, ProxMox has a much lower time and hardware level. ProxMox can be deployed in an hour or two with a failure or two, and is far, far simpler to install. However, the high availability method is its big letdown, since it is both complex and unintuitive to set up and use.

Hyper-V (Windows Service and Standalone)Windows Hyper-V is a free, standalone server, but since it began to be deployed on all Windows machines, it has become very user friendly and widely available. There are even container services available for it now. The service doesn’t even have to be downloaded on most Windows machines, only

9


enabled. It has extensive security controls for VMs, including virtual TPMs for Full-Disk Encryption, DHCP guard, and restricted access VMs for malware containment.

However, it has no remote web GUI and no Linux client. OpenStack will crush Hyper-V in situations where most servers are not Windows or need constant adjustment. Also, Hyper-V does not have a “Templates” feature yet for pre-made systems, which leaves it in the dust for mass-deployment.

XenServer (6.5)XenServer is Citrix’s standalone option of Xen with a Windows management console, using XAPI to support Linux clients. XenServer is a very solid option, especially now with containerization. It may have a slightly higher overhead than ProxMox and OpenStack, and have far less installation options, but it is very, very flexible and supports almost everything that normal Xen and XAPI would. It is also, by far, the easiest to set up High Availability on.

ConclusionUbuntu may be running 55% of all OpenStack clusters, but Deus ex Machina was not on my side when I was trying to set this system up. The entire attempt to set up took an entire day, and that was only up to step six out of fourteen, and only one service out of three. OpenStack deployed using Ubuntu Autopilot may work for me some day, but not this time.

Also, compared to some of the other Hypervisors, Autopilot leaves a lot to be desired. Most of these Hypervisors are available completely for free for an infinite number of servers. OpenStack also has a very short support life, lasting only eighteen months before the version increases. While that can be a simple “upgrade openstack”, features are added and changed with every release, so upgrades may break things. Better to stick with the old but stable version and add the new servers elsewhere.

10


Appendix I: OpenStack Services ChartOpenStack Services3¶

Service Project name Description

Dashboard HorizonProvides a web-based self-service portal to interact with underlying OpenStack services, such as launching an instance, assigning IP addresses and configuring access controls.

Compute NovaManages the lifecycle of compute instances in an OpenStack environment. Responsibilities include spawning, scheduling and decommissioning of virtual machines on demand.

Networking Neutron

Enables Network-Connectivity-as-a-Service for other OpenStack services, such as OpenStack Compute. Provides an API for users to define networks and the attachments into them. Has a pluggable architecture that supports many popular networking vendors and technologies.

Object Storage Swift

Stores and retrieves arbitrary unstructured data objects via a RESTful, HTTP based API. It is highly fault tolerant with its data replication and scale-out architecture. Its implementation is not like a file server with mountable directories. In this case, it writes objects and files to multiple drives, ensuring the data is replicated across a server cluster.

Block Storage Cinder Provides persistent block storage to running instances. Its pluggable driver architecture facilitates the creation and management of block storage devices.

Identity service Keystone Provides an authentication and authorization service for other OpenStack services. Provides a catalog of endpoints for all OpenStack services.

Image service Glance Stores and retrieves virtual machine disk images. OpenStack Compute makes use of this during instance provisioning.

Telemetry Ceilometer Monitors and meters the OpenStack cloud for billing, benchmarking, scalability, and statistical purposes.

Orchestration Heat

Orchestrates multiple composite cloud applications by using either the native HOT template format or the AWS CloudFormation template format, through both an OpenStack-native REST API and a CloudFormation-compatible Query API.

Database service Trove Provides scalable and reliable Cloud Database-as-a-Service functionality for

both relational and non-relational database engines.

Data processing service

SaharaProvides capabilities to provision and scale Hadoop clusters in OpenStack by specifying parameters like Hadoop version, cluster topology and nodes hardware details.

3 http://docs.openstack.org/admin-guide/common/get-started-with-openstack.html

11


Appendix II: Ethernet DiagramServer Port Bond Type Switchport

Enterpriseenp3s0

ALB (6)gi1/0/11

enp4s0 gi1/0/12

Yorktownenp3s0 None gi1/0/9enp4s0 None gi1/0/10

Saratogaenp3s0 None gi1/0/7enp4s0 None gi1/0/8

Oriskanyenp3s0 None gi1/0/5enp4s0 None gi1/0/6

Essexenp3s0 None gi1/0/3enp4s0 None gi1/0/4

Waspenp3s0 None gi1/0/1enp4s0 None gi1/0/2

dim5150-1 enp3s8 None gi1/0/13dim5150-2 enp3s8 None gi1/0/14vos220s (Workstation) enp3s8 None gi1/0/15

2811-Routerfa0/0 None gi1/0/24 (VLAN 10)

fa0/1 None gi1/0/21contentengine0 None NC

(Internet Access) NCS Clubroom None gi1/0/23 (VLAN 10)

12


Appendix IV: Error Images

Figure 1 – Showing the statically configured IP address that caused issues after moving networks

13


Figure 2 - Showing the 500 error that caused the Ubuntu 14.04 MAAS Server attempt to fail

14


Figure 3 - Showing the failed deletion that caused the Ubuntu 14.04 MAAS Server attempt to fail

15


Figure 4 - Showing the one server that just refused to do anything the way it was intended, especially deploy

16

Documents

Deploying OpenStack with Ubuntu Autopilot and … · Web viewDeploying OpenStack with Ubuntu Autopilot and MAAS Taylor Chien 12-14-2016 Contents Introduction2 What is the purpose