User Guide

Introduction to the User Guide

This guide gives instructions for using the Fuel Master Node and the graphical Fuel screens to deploy a Mirantis OpenStack environment.

If you already have a deployed Fuel Master Node based on version 5.x or 6.0, go to Upgrading and Updating from Earlier Releases for instructions on upgrading to Fuel 6.1 and updating your existing OpenStack distribution to use the latest maintenance release of Mirantis OpenStack. If you are deploying Mirantis OpenStack 6.1 for the first time, continue reading this document for instructions.

Before you do the procedures in this document, you should work through the information and procedures in the Planning Guide. That document discusses the planning decisions required before you install and deploy Mirantis OpenStack.

Further reading is available in the following documents:

Terminology Reference is an alphabetical listing of technologies and concepts that serves as both a glossary and a master index of information in the Mirantis docs and other sources of information.
Operations Guide gives information about advanced tasks required to maintain the OpenStack environment after it is deployed. Most of these tasks are done in the shell using text editors and command line tools.
Reference Architecture provides background information about how OpenStack works.

For community members and partners looking to take Fuel even further, see the developer documentation for information about the internal architecture of Fuel, instructions for building the project, information about interacting with the REST API and other topics of interest to more advanced developers. You can also visit the Fuel project for more detailed information and become a contributor.

Confirm hardware

Before you download and boot the Fuel Master, use the following checklist to ensure that your hardware is configured correctly:

Item to confirm	Status [tick if done]
The Fuel server has an IPMI or out of band management system and you have access to it.
The Fuel server hardware is able to boot the Fuel ISO from DVD, USB flash drive, or IPMI remote media.
The Fuel server has connectivity to all node servers through the L2 management network.
A DHCP server is NOT installed on the management network. Fuel acts as a DHCP server for the node servers configured to network boot using PXE.
Spanning tree is disabled on switch ports connected to the node servers’ ports or ports are set to edge/portfast mode. Edge/portfast mode is the preferred configuration; it allows the ports to forward immediately when they are linked up but listens for network loops for 15 seconds.
There is NO configured tagged VLAN on a switch for the administrative network (to the boot server from PXE)
The node servers are set to network boot using PXE.
The node servers have hardware virtualization enabled in the BIOS.
You have a method to reboot node servers (remotely or on-site).
The network equipment supports VLANs.
It is possible to configure a tagged port on your switch/switches. You need tagged ports in order to use the Nova-network VLAN Manager or Neutron with VLAN segmentation.
You have permit rules on TCP ports 22 and 8000 on the firewall for the Fuel server’s IP address (to access the Fuel server from your PC).

If you checked all the boxes in the above table, you are ready to deploy Mirantis OpenStack with Fuel.

Download and Install Fuel

Mirantis provides the images you will use to install Fuel and Mirantis OpenStack. Download the Fuel image from the Mirantis web-site. Depending on the speed of your Internet connection, this could take a half hour or more.

Create the Installation Media

You can download an ISO file and, for many modern servers, use a remote control utility such as ipmitool, HP iLO, or Dell iDRAC to mount the ISO image directly to the server's virtual DVD drive.

For a bare-metal installation, you can instead burn the ISO image to a DVD or USB drive, then use that media to install the software.

Note

You can use the same ISO image to install Fuel and Mirantis OpenStack in VirtualBox. In that case, copy the ISO file to the appropriate directory and boot directly from that disk file. See Running Mirantis OpenStack on VirtualBox.

Use any standard software to burn the ISO to a writable DVD. Some popular options:

Linux -- Brasero and Xfburn are commonly pre-installed applications
Mac OS X -- Open Disk Utility from Applications > Utilities, drag the ISO into the disk list on the left side of the window and select it, insert a blank DVD, and click Burn. If you prefer a different utility, check out the open source Burn.
Windows -- Use ImgBurn or the open source InfraRecorder.

Create a USB drive to store the Fuel ISO image on a UNIX system

You can use a USB flash drive to install Fuel on your machine. Write the ISO image to the USB flash drive, but not to the partitions of the USB flash drive. For example, if you have a USB flash drive /dev/sdc with the /dev/sdc1 and /dev/sdc2 partititions, write the USO to /dev/sdc.

To create a USB flash drive with the Mirantis OpenStack ISO image:

dd if=/path-to-iso of=/path-to-usb

Example::

dd if=/home/user/fuel-isos/fuel-6.1-248-2015-03-30_03-08-59.iso of=/dev/sdc

Warning

All data on the USB flash drive will be lost.

Install Fuel Master Node

Insert (or mount through IPMI) the media you created in Download and Install Fuel on the server that will be your Fuel Master Node and power the machine on, just as you would for any operating system installation. Set the boot order for the system with the installation media as the first device. Or you can set the hard drive as the first device, then select the location of the media that contains the installation file to install the software. The following screen appears.

If necessary, you can modify the boot settings from this screen; press the "Tab" key to display the grub command line and edit that line. This allows you to configure the IP address, default gateway, and DNS server for the Fuel Master Node.

Note

It is possible to install Fuel Master node on vSphere. For more details, see Installing Fuel Master Node on vSphere.

Changing PXE Network Parameters During Installation

You may also need to customize the network settings for the Admin (PXE) logical network.

Note

The VirtualBox automated scripts depend on the network configuration in the config.sh file so the virtual Fuel Master Node can connect to the virtual nodes correctly. Do not use Fuel Setup to configure the Admin network interface when using VirtualBox; however, you can view this Fuel Setup screen by modifying the vm_master_ip parameter in the config.sh file.

By default, eth0 on the Fuel Master node listens to PXE requests from the Fuel Admin (PXE booting) network, which has a default network of10.20.0.2/24 and the gateway 10.20.0.1.

PXE network settings may be changed with two ways - via kernel options (for eth0 interface only) and via the console-based Fuel Setup.

Warning

Settings made with console-based Fuel Setup take precedence over the kernel options!

Note that,

Changing the IP address in the kernel options also changes the CIDR for the Admin network.
Changing the IP address on the Admin network interface requires changes to the DHCP range values in the PXE Settings screen.
New default DHCP values that fit into this range are auto-populated, but be sure that the range does not conflict with other devices on the network.

Kernel options allow you to customize eth0 network settings, which will be used for Admin (PXE) network if you will not change these later with Fuel Setup. Customizing eth0 interface via kernel options also gives the ability to connect to the master node early, which is useful if the master node installation fails.

Fuel Setup

The console-based Fuel Setup allows you to customize the Admin (PXE) logical network if you want to use a different network interface. SeeLogical Networks for more information about the Admin (PXE) logical network.

This tool provides a simple way to configure Fuel for your particular networking environment, while helping to detect errors early so you do not need to troubleshoot individual configuration files.

Within Fuel Setup, you can configure the following parameters:

DHCP/Static configuration for each network interface
Select interface for Fuel Admin network
Define DHCP pool (bootstrap) and static range (installed nodes)
Set NTP servers for Time settings
Root password
Fuel password
DNS options
Launch shell for optional pre-deployment tasks

Use the arrow keys to navigate through the tool and Space or Enter key to select an item.

Network Setup

This section is used to set network interface settings. It shows all network interfaces currently available. During the first boot, it shows only available ethX NICs; if you run Fuel Setup on already deployed Fuel Master node it will additionally present you vethXXX interfaces. You may set configuration for each interface, enable or disable particular NICs.

Unlike the other tabs, this tab has the ability to immediately apply only changes related to this tab.

Warning

All the settings on this tab may be performed manually with standard Linux IP tools. Actually, Fuel Setup use these tools as well. So, if complex network setup required before Fuel Setup, there is possibility to use Shell Login from Fuel Setup during the first boot, perform necessary network settings with proper care, return back to the Fuel Setup and continue with master node installation.

Configuring Network settings

Network settings has 2 parts - editable Network settings and non-editable Network Interface current status. NIC current status area shows the current network interface status, including name, Link Status, current IP address, MAC address, Netmask and Gateway.

Network Settings from the editable Network Setup part become effective only after they are applied with the Apply button.

Network Setup includes the following configurable sections:

Network Interface Selector - Shows all available network interfaces, physical and virtual. Select the interface you want to configure with arrow keys and click Space or Enter to show its configuration.
Interface name - Here you may rename the selected network interface.
Enable interface - Here you may turn the selected network interface ON or OFF.
Configuration via DHCP - You may set interface to get settings from the existing external DHCP server. Do not set DHCP=Yes for the network interface you are going to use for Admin (PXE) network!
IP Address - allows to set static IP address for selected NIC.
Netmask - allows to set network mask for selected NIC.
Default gateway - allows to set the gateway for selected NIC.
Button Check - Validates the unsaved settings on the Network Setup section without applying.
Button Apply - Validates the unsaved settings on the Network Setup section and makes the new settings effective.

Assume you are going to change PXE NIC from eth0 to eth1. eth0 is already up and its IP address is 10.20.0.2, set via kernel options. You want eth1 to use the same IP address. Additionally, you want to set eth2, connected to your corporate network as the interface where Fuel web UI will be accessible. eth2 should use DHCP.

Your actions:

Select eth0 on the Network Setup tab. Change Enable interface option from Yes to No.
Apply settings. It will turn off eth0. You need this since we do not want the same IP address configured on both eth0 and eth1 at the same time.
Select eth1 on the Network Setup tab. Change Enable interface option to Yes. Set IP address to 10.20.0.2, set the proper netmask and gateway.
Apply settings. Now you have set eth1 ready to be used as PXE interface.
Select eth2 on the Network Setup tab. Change Enable interface option to Yes. Set Configuration via DHCP=yes. Leave IP address, Netmask and gateway blank.
Apply settings. Now you have eth2 available in your corporate network.

And do not hesitate to use Check button to verify your future network settings in advance.

Warning

To set the master node network interfaces properly, one must set and APPLY correct network settings on the Network Setup tab BEFORE proceeding with PXE setup.

_images/fuelmenu_Network_Customized_Setup.png

Once you have finished with the network Setup you may proceed to PXE Setup tab.

PXE Setup

Warning

This section must be configured only in the scope of the Fuel Master node's first boot! Setting new network settings for the already installed master node requires that all Docker containers be rebuilt and possibly further manual reconfiguration!

Here you may select the network interface you are going to use for PXE/Admin network and set DHCP pool ranges.

PXE Setup has 2 parts - editable PXE settings and current status information about the selected Network Interface that cannot be edited. NIC current status area shows the current network interface status, including name, Link Status, current IP address, MAC address, Netmask and Gateway. It also shows warnings, related to the currently selected NIC misconfiguration.

PXE setup includes the following options:

Network Interface Selector - Shows all available network interfaces, physical and virtual. Select the interface you want to configure with arrow keys and click Space or Enter to show its configuration.
DHCP Pool for node discovering - Here you may define DHCP Pool Start and End IP addresses. These addresses should be located inside the CIDR that is configured for the currently selected NIC.
Check button - verifies the current unsaved settings against the currently selected NIC without applying.

Let us continue the example we started in the Network Settings section:

Use the Space or Enter key to mark and select the network interface you have configured for PXE on the Network Setup tab. The default PXE interface is eth0. If you follow the example from Network Setup part of this guide, you have to select eth1.
Set the proper DHCP Pool range values.
As usual, use Check button to verify the current unsaved settings.

Warning

Modifying the PXE NIC with Fuel Setup when the Fuel Master node is already deployed will break Fuel's ability to PXE boot and manage OpenStack environments. If you wish to modify PXE NIC configuration, you should only do so by destroying all OpenStack environments, and then run the following commands: dockerctl shell nailgun, manage.py dropdb, dockerctl destroy all, dockerctl start all.

DNS & Hostname

Use this section to configure the remained master node network settings. These settings may be reconfigured after the master node has been deployed.

Details on settings:

Hostname - master node host name (without domain)
Domain - master node domain name. If the master node has several network interfaces, you may connect non-PXE one to the existing corporate network and set the real domain name. Otherwise, use default or any valid stub name.
Search domain - in most cases, should match the Domain field, unless you know what you are doing.
External DNS - Point it to the corporate or Internet-based DNS server if your master node is connected to the corporate network by Non-PXE network interface. Otherwise - leave blank, since it may block Fuel Setup from network settings save due to failed DNS test.
Hostname to test DNS - any existing host name, which Fuel Setup may ping in order to check DNS settings.

Please do not hesitate to use Check button to verify your future network settings in advance.

Time sync with NTP

Use this section to set NTP server names in order to get proper time synchronization. Synchronized time is mandatory for OpenStack services.

If you have access from master node to the external or corporate network - it is strongly recommended to set proper NTP server names or IP addresses.

If your master node currently has no access to the external or corporate network - leave all 3 fields blank. You may set these later.

If you set NTP server names blank and enable NTP - master node will serve your OpenStack installations as NTP server, but will not synchronize time with NTP. It may lead to a time shift between your OpenStack installations and the rest of the world.

If you disable NTP completely - your deployed OpenStack will not use NTP and most probably will end with the timing errors, unless you have an external solution to synchronize clocks between the nodes.

Please do not hesitate to use Check button to verify your future network settings in advance.

Root password

Here you may set new root password for your master node. This password serves as the default root password for all future OpenStack nodes. Already existing OpenStack nodes will keep the existing password. Leave these fields blank in order to keep the default root credentials.

Button Check verifies if both password fields match and has correct data.

Fuel login

This section enables you to modify the password used to log into the Fuel Dashboard:

Changing this password here changes the password value in the astute.yaml file. You can also modify the password from the Fuel UI screens and the Fuel CLI. See Fuel Access Control for more information about Fuel passwords.

Quit Setup

Options:

Save and Continue - runs built-in tests. If tests passed successfully - saves the current settings from all sections, except the first one, Network Setup, which has its own Apply button. Gives you the ability to check settings and save intermediate changes.
Save and Quit - runs built-in tests first. If test passed successfully - saves the current settings from all sections, except the first one, Network Setup, which has its own Apply button. After the settings saved, it quits Fuel Setup and, if it is first boot, continues with Fuel master node installation.
Quit without Save - discards all the current settings from all sections, except the first one, Network Setup, which has its own Apply button and quits the Fuel Setup.

Once you have made your changes, go to Save & Quit.

You can run fuelmenu from a root shell on the Fuel Master node after deployment to make minor changes to network interfaces, DNS, Time Sync and the gateway. The PXE settings, however, must not be changed after deployment as it will lead to master node failure. Option to change PXE settings remains active for those who are familiar with master node manual settings

Warning

Once IP settings are set at boot time for Fuel Master node, they should not be changed during the entire lifecycle of Fuel.

Boot the Fuel Master Node

When installation is complete, be sure to remove the installation media from your system. This is especially important if you set the boot order so that the USB/DVD drive is before the hard disk; you may accidentally boot the installation media again and damage or delete your environment.

The boot messages display on your screen as Fuel boots up:

When the system has booted, you can log in:

Use the administrator login and password that are displayed on the boot screen to log into a shell on the Fuel Master node. After you log in, use the passwd command to change this password.
Use the URL displayed on this screen to launch the Fuel UI; the default URL is http://10.20.0.2:8000/. This is your URL unless you modified the IP address on the Fuel Setup screens.

Use the admin user name and the Fuel password you set in in the Fuel Setup screens (see Fuel login) to log in. If you did not set a Fuel password during installation, log in using admin/admin as the username/password. You can change the password from the Fuel UI; seeChange Fuel Password.

Alternately, if the server on which the Fuel Master is installed has more than one NIC, you can use the second NIC to access the Fuel UI:

Connect the NIC to the appropriate switch
Set the IP address for this NIC
Use the IP address you set to access the Fuel UI.

Note that doing this does not change the Admin network settings; the URL displayed on the Fuel boot screen is unchanged and can still be used.

Boot the node servers

After the Fuel Master Node is installed and booted, power on all target nodes that you are going to use for the OpenStack environment. First, ensure that servers are physically connected to the same network as the Master node or, if you are using virtual servers, are bridged to it so they are in the same L2 network segment. Then you can boot each node (other than the Fuel master) via PXE by either modifying the BIOS boot order or pressing the appropriate key to initiate a PXE boot. If your nodes have several network interfaces, be sure to enable PXE-boot on the interface that is on the same network you configured for PXE booting on the Fuel Master Node.

Each node sends out DHCP discovery requests and gets the response from the Fuel Master node that runs the DHCP server.
When a node receives the response from the Fuel Master node, it fetches the pxelinux bootloader and then the bootstrap image (CentOS based Linux in memory) from the Fuel Master node's TFTP server and boots into it.
When this image is loaded, it reports the node's readiness and configuration to the Fuel Master. This can take a few minutes.

Follow the instructions in Boot the Fuel Master Node to log into the Fuel UI if you have not already done so. You will see notifications in the user interface about the discovered nodes. Find the count of "Discovered nodes" in the upper right area of the Fuel Web UI; this value is incremented as each new node is ready. When the count of "Discovered nodes" becomes equal to the amount of the servers you have booted in the network, you can create an OpenStack environment, add nodes into it, and start configuration.

Networking configuration is the most complicated part, so please read Choose Network Topology and the other documents it references before you begin.

When you have configured all the nodes and their roles, and pressed the Deploy button:

Each server should reboot and start the provisioning of the selected operating system using the same PXE boot scheme, so ensure that all the servers have successfully rebooted, booted over the network and started the installers.
When all servers have been successfully provisioned and rebooted again from their local drives into the newly installed systems, the Fuel Master node starts the deployment of OpenStack on them.

Note

Beginning with 6.1 release, nodes discovery is enabled over the prepared Infiniband network via Fuel over Mellanox NICs with Infiniband support, after Mellanox Fuel plugin installation. This means, the Fuel Master node will discover and use EIPOIB daemon (Ethernet IP Over Infiniband) interfaces for the network roles. Note, that interface driver and bus information are now available for all discovered NIC interfaces. For detailed instructions, see Verify Infiniband links for nodes section in the official Mellanox documentation.

Install Fuel plugins

Overview

Beginning with Mirantis OpenStack 6.0, Fuel features the ability to install plugins before you deploy your environment. Plugins are downloadable software components that extend the functionality of your environments in a flexible, repeatable and reliable manner.

For example, Neutron VPNaaS provides flexible IPSec VPN feature-set supported by Neutron CLI and, more simply, in Horizon, by adding a new set of tabs to Network.

Validation

The Fuel Plugins Validation is a set of technical and business processes that Mirantis uses to verify Fuel plugins built by vendors, allowing a customer's choice of plugins to lead to a predictable outcome. That means, Mirantis Validation ensures the quality of developed solution.

In terms of Validation, Fuel plugins fall into two categories:

Validated - thoroughly reviewed, tested and supported by Mirantis.
Non-Validated - reviewed, tested in terms of code and installation procedure, but not supported by Mirantis.

See the validation requirements at Mirantis website.

For information on development requirements and FAQ, see Fuel Plugins wiki page.

Installation steps

Installation procedure is common for all plugins, but their requirements differ.

Download a plugin from Fuel Plugins Catalog.
Get acquainted with the plugin documentation to learn about prerequisites and limitations.
Copy the plugin on already installed Fuel Master node. If you do not have the Fuel Master node yet, see Mirantis Quick Start Guide.
```
scp <fuel_plugin-file> root@:<the_Fuel_Master_node_IP>:/tmp
```
Log into the Fuel Master node and install the plugin:
```
cd /tmp
fuel plugins --install <fuel-plugin-file>
```
After your environment is created, open Settings tab on the Fuel web UI, scroll down the page and select the plugin checkbox. Finish environment configuration and click Deploy button.

For Fuel plugins CLI reference, see the corresponding section.

Create a new OpenStack environment

After you complete the steps in Download and Install Fuel, the Fuel UI screen shows all your Slave nodes as "Unallocated nodes"). You can now create, configure, and deploy your first OpenStack environment. One Fuel Master can deploy and manage multiple OpenStack environments but you must create each environment separately.

Step Description	Additional Information
Click on the "New" OpenStack environment" icon to create a new environment.	See Launch Wizard to Create New Environment
Modify the Fuel password (optional)	See Change Fuel Password
Approve collection of anonymous statistics	See Approve Statistics Gathering
Choose the name for your environment and choose the Operating System (distro)	See Name Environment and Choose Distribution
Choose your Hypervisor	See Hypervisor
Select your network service (Nova-network, Neutron with GRE segmentation or Neutron with VLAN segmentation.	See Network service. If you choose Nova-network, you can choose FlatDHCP or VLAN Manager later in the Network settings tab.
Select your storage backends for Cinder and Glance.	See Storage backend for Cinder and Glance
Choose additional related projects.	See Related projects
Select Create and click on the icon with your named environment.	See Complete the creation of your environment

Launch Wizard to Create New Environment

If you have not already done so, point a browser window to http://10.20.0.2:8000/ to log into the Fuel UI. See Boot the Fuel Master Node for more information.

The Fuel Login screen appears:

Use the admin username and the Fuel password you created above.

The Fuel UI screen appears:

Click on the "New OpenStack environment" icon to launch the wizard that creates a new OpenStack environment.

If you are deploying a Mirantis OpenStack environment that is integrated with VMware vSphere, follow the instructions in Deploying vCenter.

Change Fuel Password

You can change the Fuel password from the Fuel UI screen; click on "Change password" at the upper right of the screen. The following screen is displayed:

Type in the old password and then the new password, confirm the new password; click on the eye icon on the right of each line to display the string you typed.
Click "Apply" to register the new password and return to the previous page.

See Fuel Access Control for more information about Fuel passwords.

Approve Statistics Gathering

Use this screen to define the statistics that are sent to Mirantis about your environment:

You have the following options:

Send usage statistics collects and sends anonymous usage statistics such as settings, actions, hardware configuration, and version information. The usage statistics are completely anonymous and do not include information such as passwords, IP addresses, or node names. Uncheck this box to disable the collection of usage statistics.
Identify my error reports authorizes Mirantis to associate error reports generated for your environment so that Mirantis Support staff can assist you.

Note

The Community version of Mirantis OpenStack has a different version of this screen that does not include the "Identify my error reports" section.

If you do not have a Mirantis account yet, click Create Account and enter the contact information that Mirantis Support can use.

If you do not remember your password, click Retrieve Password.

_images/statistics-retrieve-password.png

Name Environment and Choose Distribution

When you click on the "New OpenStack Environment" icon on the Fuel UI, the following screen is displayed:

Give the environment a name and select the Linux distribution from the drop-down list:

Juno on Ubuntu 14.04.1 (2014.2.2-6.1)(default)
Juno on CentOS 6.5 (2014.2.2-6.1)

This is the operating system that will be installed on the target nodes in the environment. See Linux Distribution for Nodes for guidelines about choosing the distribution to use.

The number in parentheses is the version number for each environment version; it is formed by concatenating the Juno Release number and the Mirantis OpenStack Release number. In this case, the "2014.2" string corresponds to the Juno release version; the "6.1" string is the Mirantis OpenStack release number.

Note that the list displayed under the "Releases" tab at the top of the Fuel home page lists all the releases that Fuel 6.1 can manage in your environment. If you upgraded Fuel from an earlier Mirantis OpenStack release, Fuel 6.1 can manage environments that were previously deployed using those releases. It cannot, however, deploy a new environment using those releases.

High-availability (HA) mode

Prior to Fuel 6.1, it was possible to choose between multi-node and multi-node with HA modes. Starting from Fuel 6.1, the only supported deployment mode is HA.

Hypervisor

Choose one of the following:

KVM -- Choose this option for bare-metal installations.
QEMU -- Choose this option for VirtualBox installations.
vCenter -- Choose this option if you have a vCenter environment with ESXi servers to be used as hypervisors.

Note

Beginning with Fuel 6.1 release, you can select two hypervisors (vCenter+QEMU or vCenter+KVM) to enable dual hypervisor support in one environment. To do that, you should choose between KVM and QEMU and click the corresponding radiobutton. After that, you only have to select the vCenter checkbox. If you would like to have vCenter hypervisor only, then you should select vCenter checkbox, enter the settings and avoid adding compute nodes. For instructions, see VMware tab section.

Network service

Five network topologies are supported; see Choose Network Topology.

You can choose any of the Neutron topologies on this screen. If you choose Legacy Networking (nova-network) here, you can choose between the FlatDHCP and VLAN topologies on the Network Settings page.

Storage backend for Cinder and Glance

The default providers are LVM for Cinder, local device for Swift, and Swift for Glance.

Before the deployment starts, you can change these settings on the Storage screen, where you can also set the Ceph replication factor.

See Choosing the Storage Model for more information about Cinder, Glance, and Ceph.

Complete the creation of your environment

Select "Create" and click on the icon for your named environment.

When Fuel reports that your environment has been created, you can click on "New OpenStack Environment" to create another environment, or you can click on the icon for your environment to display the Fuel console from which you can configure and manage your environment.

Configure your Environment

After you create your OpenStack environment, click on the icon for that environment. Fuel displays a set of configuration tabs that you use to finish configuring your environment.

Step Description	Additional Information
Add nodes to your environment	See Add nodes to the environment
Assign a role or roles to each node server.	See Assign a role or roles to each node server
Customize disk partitions	See Disk partitioning
In Network tab, configure the network settings from the address plan prepared earlier.	See Network settings
Set up NIC bonding (optional)	See Setting NIC bonding (NIC aggregation)
Map logical networks to NICs	See Mapping logical networks to physical interfaces on servers
Click Verify Networks to check and confirm the network configuration.	See Verify Networks
(Optional) In the Settings tab, you can configure or modify the options for Horizon access, scheduler type, logging, and other OpenStack options.	See Settings tab
Click the Deploy Changes button.	See Deploy Changes
(Optional) Set up and test Sahara	See Installing Sahara

Each of these steps is discussed below in more detail.

If necessary, you can stop deployment or reset the environment.

Add nodes to the environment

The initial screen shows the total number of nodes that have been discovered in your environment and the number of nodes that are unallocated. Click on the "Add nodes" button to add nodes to your environment:

Assign a role or roles to each node server

The first screen that is displayed has a list of roles at the top and a list of unallocated nodes at the bottom.

A node is a physical or virtual server that is provisioned to run a specific set of OpenStack services.
A role is a functional set of services that Fuel installs as a whole on a node, usually in its own disk partition.

To assign roles to the nodes:

Select the role or roles you want to assign; roles that cannot be assigned are indicated.
Click on the appropriate node(s) in the "Unallocated Nodes" list.
Click on the "Apply Changes" button.
Proceed to do this until roles have been assigned to all nodes.

As you make your selections, Fuel displays an icon (a gold triangle with an exclamation point) next to roles that are not allowed. It also tells you about other environment settings that are required.

If you want to modify the roles assigned to a node:

If you assigned the wrong role to a node (for example, you defined a node as a Compute node but want it to be a Ceph OSD node), select that node and click the "Delete" button. This moves that node back to the pool of "Unallocated nodes" so you can click on "Add Node" to assign a new role.
If you want to add a role to a node (for example, you defined a node as a Compute node but want it to also have a Ceph OSD role), select that node and click the additional roles you want to assign (in this case, click the "Ceph OSD" node and leave the "Compute" role selected); click the "Apply Changes" button.

When you click the "Apply Changes" button, Fuel displays the configuration you have chosen:

To rename the nodes, click on the "Untitled" string for each node and then type in the name you want to use. The suffix is the last digits of the MAC address for this node; you can keep these digits or delete them.

Beginning with Fuel 6.1, you can remove a node from inventory if it is dead or there is need to delete it from the cluster. To do that, you should click Forget button next to the required node. This works for any offline node both deployed and not. To remove any node from inventory using the Fuel CLI, see Remove a node from Fuel DB.

For more information, see:

OpenStack Environment Architecture describes the Controller, Compute, and Storage nodes.
Choosing the Storage Model for more details about the ramifications of the different Storage roles.
Nodes and Roles includes guidelines about setting up nodes.
MongoDB for information about MongoDB.
Operating System Role defines the Operating System role and points to other documents with additional information.

Disk partitioning

Fuel allocates some reasonable amount of disk space for each role that is assigned to a node. To modify this allocation, select the node(s) you want to modify and click on the "Configure Disks" button. You can also access this screen by clicking the gear wheel to the right of the node listing; in the detailed information window that is displayed, click the "Configure Disks" button.

This displays a screen with a bar for each disk; color-coded sections represent the disk partitions that have been assigned.

The following partition types may be configured:

Base System: comprehensive of swap space, includes operating system and basic software
Virtual Storage: used by Nova running instances
Image Storage: used by Glance to store images
Cinder: used by Cinder
Ceph and Ceph Journal: used by Ceph
MongoDB: used for Ceilometer information stored in MongoDB
Mysql database: stores Zabbix statistics on Zabbix nodes

To modify the disk allocation, click on the bar for a disk. This example is for a node that runs both a Compute node and a Storage - Cinder role; clicking on the center bar gives a display similar to the following:

To change the disk allocation for a specific role, just type in the amount of space (in MB) you want to allocate. You can use round numbers; Fuel adjusts this number to satisfy block size boundary requirements and such. The display adjusts to show the new allocation; click on the "Apply" button in the lower right of the screen to save the modifications and return to the Node List. Click on the "Back to Node List" button in the lower left of the screen if you do not want to change the disk allocation.

Note the following:

Disk partitions can be customized only after a role is assigned to the node.
If you have multiple nodes that have identical hardware and identical roles, you can partition all their disks at the same time by selecting them all and then clicking the "Configure Disks" button.
If the node's roles are modified, the disk configuration is reset to default values.

Network settings

Use the "Network Settings" tab to notify Fuel about the network hardware that is configured. Different pages are used, depending on the network topology you chose on the Network service screen.

For more information, see Public and Floating IP address requirements.

Neutron network settings

These example screens are for a Neutron deployment, which includes sections for setting the L2 and L3 configuration that are not provided for Nova-network deployments.

Nova-network settings

These example screens illustrate the Network Settings page when using Nova-network:

Setting NIC bonding (NIC aggregation)

NIC bonding is an optional step that allows you to aggregate multiple physical links into a single link; this increases the speed and provides fault tolerance for the network connection. NIC bonding should be done before or in the scope of mapping logical networks to NICs.

Use "Configure Interfaces" tab to configure interface bonding.

Select node(s) and click "Configure Interfaces". Select interfaces to be aggregated. All interfaces except Admin-PXE can be aggregated.

Click "Bond interfaces". Now you can select the appropriate bonding mode from the "Mode" drop-down list.

Reassign networks, create additional bonds, etc. You can make all required changes and click "Apply" after that.

You can add one or more interfaces to the bond. Select a bond and the interface(s) to add, then click "Bond Interfaces". Interface(s) can be removed from the bond when the bond has 3 or more slave interfaces. To remove an interface from a bond, click "Remove" at the left-bottom from interface icon. To unbond interfaces, select bond and click "Unbond Interfaces".

Mapping logical networks to physical interfaces on servers

Fuel allows you to use different physical interfaces to handle different types of traffic; see Logical Networks for more information. A logical network can be mapped to either a NIC or to a bond of NICs.

To access this screen, select a node or nodes and click the "Configure Interfaces" button. You can also access this screen by clicking the gear wheel to the right of the node listing; in the detailed information window that is displayed, click the "Configure Interfaces" button.

On this screen, you can drag-and-drop logical networks to physical interfaces according to your network setup.

All logical networks other than the Admin ("Fuel") network are presented on the screen. It runs on the physical interface from which the node was initially PXE booted, In the current version, it cannot be mapped onto any other physical interface.

Note that, once the network is configured and OpenStack is deployed, you may not modify network settings, even to move a logical network to another physical interface or VLAN number.

Verify Networks

When you have applied all your information to the "Network Settings" screen, click the "Verify Networks" button at the bottom of the screen. This checks and confirms the network configuration

The network check includes tests for connectivity between nodes via configured VLANs on configured host interfaces. Additionally, checks for an unexpected DHCP server are done to ensure that outside DHCP servers will not interfere with deployment. The image below shows a sample result of the check. If there are errors, it is either in your configuration of interfaces or possibly the VLAN tagging feature is disabled on your switch port.

Resolve any errors before attempting to deploy your environment. After doing that, run the check once more. The Verification succeeded message should appear.

Note

Currently, network verification does not check interfaces in bonds taking them for simple interfaces. In case of LACP L2 bonding, verification fails on the hardware. Due to this problem, interfaces in LACP bonds are excluded from the checklist.

Beginning with Fuel 6.1, if you press Deploy button the Fuel web UI will display network verification warnings in the following three cases:

you have not verified networks at all:
your network verification is in progress:
your network verification failed:

Settings tab

The "Settings" tab allows you to set or modify various values for the system. Many other values can be set by editing configuration files and running command-line tools on the nodes.

The "Settings" tab provides configuration access to:

Security: reset login credentials for Horizon, set/reset login credentials for vCenter, set the SSH Public Key that will be authorized to access target nodes.
Logging: set configuration parameters for Syslog, turn debug logging on/off
Modify the characteristics defined when you first created the Fuel environment, including which additional components (Sahara, Murano, and Ceilometer) are included, the hypervisor type, and the storage backend that are configured.
Instance management: whether to automatically assign a floating IP to a new instance, whether to restart guests when the host reboots, and which scheduler to use to determine how to dispatch compute and volume requests.

After you modify values on the "Settings" screen, click the "Load Settings" button at the bottom of the screen. If you want to go back to the Fuel default values, you can click on the "Load Defaults" button at the bottom of the screen.

Access permissions for Horizon

This section of the Settings screen allows you to modify the user name, password, and tenant used to access the Horizon dashboard.

Provision Method

This section appears on the Settings tab of Fuel Web UI where you can choose between Classic Fuel Provisioning (which uses the native CentOS or Ubuntu installation mechanisms) or the Image based provisioning (which copies pre-built OS images on nodes):

Repositories

Define repositories to download the operating system and various updates. For detailed information see Configuring repositories.

Services included in the environment

Use this screen to modify the services you chose on the Related projects screen when you first created your environment.

Common settings

This section of the screen enables you to:

Turn debug logging on/off
Define Nova quotas
Modify the Hypervisor choice you made when first creating your environment
Choose whether to auto-assign floating IPs
Choose the scheduler driver to use in the environment
Select whether to use qcow format for images
Select whether to start/restart guests when the host boots
Set Public key for deployed nodes

Setting debug level for the environment

Use this field to set DEBUG level logging for all services in the environment:

Debug logging consumes massive amounts of disk space as well as memory and CPU resources on the Fuel Master node and all OpenStack nodes in the environment. It should not normally be run unless you are attempting to diagnose a problem, and you may want to offload or delete the logs generated when you are finished with them.

Choose the Compute Node Scheduler

The Filter Scheduler, Nova uses a set of filters plus a weighting algorithm to determine the best Compute Node on which to deploy a new VM instance. The Filter Scheduler is generally superior to the older scheduler and should be used for most environments; use this screen to choose the older scheduler if necessary.

Choose image format

Select image format for ephemeral storage.

When this option is selected, ephemeral volumes will be created as a copy-on-write layer of the base image. Without this option selected, ephemeral volumes will be full copies of the base image. The default setting is to use copy-on-write for ephemeral volumes. This option has no effect when using Ceph for ephemeral storage.

Public Key

The Public Key field defines the SSH key that will be used by each target node. Fuel pushes this key to each target node that is created in the initial deployment and to each node that is added to this environment after the initial deployment.

Note that the Public Key defined here is used only for the target nodes in this environment; if you create other environments, you must configure the public key for each of them.

See Uploading Public Keys for information about uploading a public key to the Fuel Master node.

Setting initial kernel parameters for target nodes

Use the "Initial parameters" box to set kernel parameters for all target nodes that Fuel will deploy:

Note that this does not set kernel parameters for the Fuel Master node or for nodes that have already been deployed; see ref:kernel-parameters-ops.

For more information, see How To: Modify Kernel Parameters

Configuring syslog

Fuel deploys the OpenStack environment to use the standard Linux syslog facility to log the activity of all services. By default, rsyslog is configured to use the Fuel Master node as the remote syslog server that contains all logs generated on all nodes in the environment.

If you prefer to use an external server for rsyslog, specify the IP address and port number in this field:

See Logs and messages for more details.

Mellanox Neutron components

This section explains how to configure Mellanox ConnectX-3 adapters in your environement. See Mellanox ConnectX-3 network adapters for planning information.

Kernel parameters configuration:

When enabling SR-IOV or iSER block storage, the intel_iommu=on kernel parameter will be automatically added on all nodes.

Mellanox Neutron plugin configuration:

In order to work with other plugins without SR-IOV, such as OVS, please select "Install only Mellanox drivers".
In order to work with SR-IOV mode, select "Install Mellanox drivers and SR-IOV plugins". After choosing the Mellanox SR-IOV plugin, an editable text box for changing the number of virtual functions is enabled.

Note: The maximum number of supported vNICs is 16. See HowTo Install Mirantis Fuel 5.1 OpenStack with Mellanox Adapters Support to get instructions for changing the maximum number of vNICs.

iSER configuration:

In order to use high performance block storage, select "ISER protocol for volumes (Cinder)" checkbox in the storage section.

The requirements for enabling iSER are:
- "Cinder LVM over iSCSI for volumes" should remain selected.
- Either "Install only Mellanox drivers" or "Install Mellanox drivers and SR-IOV plugins" should be checked in the Mellanox Components section.

Note: HowTo Install Mirantis Fuel 5.1 OpenStack with Mellanox Adapters Support includes advanced information regarding Mirantis Openstack installation over Mellanox hardware.

Storage

You can use this screen to modify the choices made for persistent storage on the Storage backend for Cinder and Glance screen. You can also select Ceph RBD storage for ephemeral volumes on this screen.

Be sure that you have assigned the appropriate roles on the Assign a role or roles to each node server screen to support the storage backends you select here. For example, if you configure any Ceph storage options here, you must configure an appropriate number of Ceph OSD nodes; if you configure a Cinder LVM over iSCSI role here, you must configure a Cinder LVM node.

The "Ceph replication factor" value determines the minimum number of Ceph OSD nodes that must be deployed. At least three Ceph OSD nodes are recommended for production environments but it is possible to set this value to 1 and then run OpenStack with a single Ceph OSD node.

Resetting the Zabbix password

You can reset the Zabbix password on this screen:

Deploy Changes

When you have made all the configuration changes you want to make, click the "Deploy Changes" button to deploy the environment you have defined.

When you are satisfied with your configuration, click on the "Deploy Changes" button. The following screen is displayed to summarize the configuration modifications you have made:

This is your last chance to change the configuration; check it carefully and, if this is not the configuration you want to deploy, click "Cancel". If this is the configuration you want, click "Deploy"; after this, you cannot modify the configuration without starting over.

It can take fifteen minutes to an hour to deploy Mirantis OpenStack, depending on the options chosen; deployment times out at two hours. You can monitor the progress by opening the Nodes tab or by checking individual node logs in the Logs tab.

Stopping Deployment from Web UI

Click on the small red button that appears to the right of the progress bar after you click "Deploy changes" and deployment itself starts:

Clicking this button interrupts the deployment process; this is useful if, for example, you realize you made an error in the configuration. This may lead to one of two possible results:

If no nodes have finished deployment (reached "ready" status), all nodes are rebooted back to bootstrap. The environment is reset to the state it had right before "Deploy Changes" was pressed; the environment may then be redeployed from scratch. Two things will happen in UI:
- All nodes are marked as offline and are eventually return back online after reboot. You can not deploy an environment that includes offline nodes, so the next deployment should not be started until all nodes have been successfully discovered and reported as online in the UI.
- All settings will be unlocked on all tabs and for all nodes, so that you can change any setting before starting a new deployment.
This is quite similar to resetting the environment (Resetting environment after deployment).
Some nodes are already deployed (usually controllers) and have reached "ready" status in the UI. In this case, the behavior is different:
- Only nodes which did not reach "ready" status are rebooted back to bootstrap; deployed ones remain intact.
- Settings remain locked because they have been already applied to some nodes. You may reset the environment (Resetting environment after deployment) to reboot all nodes, unlock all parameters, and redeploy an environment from scratch to apply them again.

Resetting environment after deployment

The deployment process may be completed in one of three ways (not including deleting the environment itself):

Environment is deployed successfully
Deployment failed and environment received an "error" status
Deployment was interrupted by clicking "Stop Deployment" button (see Stopping Deployment from Web UI)

Any of these three possibilities causes the "Reset" button in the "Actions" tab to become unlocked:

Click this button to reset the whole environment back to the state it was in right before the "Deploy changes" button was first clicked.

All nodes will be offline; they will come back online after reboot. You can not deploy an environment that includes offline nodes, so you should start the next deployment after all nodes have been successfully discovered and reported as online in UI.

All settings will be unlocked on all tabs and for all nodes, so you can modify any setting before starting a new deployment.

Note, that beginning with Fuel 6.1, the Fuel web UI displays warnings if you try to press Deploy button with network verification in progress, failed or skipped. See Verify networks for more details and screenshots.

Next Steps

After you successfully deploy your OpenStack environment, you should do the following:

Set up shell access to the Fuel Master and target nodes. You will need to use some shell commands to manage your environment.
Run some tests to ensure that the deployed environment is sound:
- Run Verify Networks. Even though you ran this before you deployed the environment, it is wise to run it again on the deployed network. Network Troubleshooting may be useful.
- Run the Post-Deployment Check tests, including the "Additional Checks" listed.
- Run the Post-Deployment checks for other services if you included them in your environment:
  - Sahara
  - Murano
- Check other components:
  - If you implemented Ceph as your storage back-end, follow the Verifying the deployment instructions to check the deployment. If you find problems, Troubleshooting Ceph may help you resolve them.
Run a backup and store the backup in an appropriate location.
To rename, reset, or delete an environment, click on the Actions tab on the Fuel dashboard and follow the instructions on the screen.
Manage your environment using the Horizon dashboard (click on the link on your Fuel Dashboard) and command-line tools:
- For more information about using the Horizon dashboard, see the OpenStack User Guide.
- Create projects/tenants and users; see Managing Projects and Users.
- If you deployed an OpenStack environment that is integrated with the vCenter server, see Running vCenter for information about managing the environment.

Post-Deployment Check

Even a successful deployment may result in some OpenStack components not working correctly. If this happens, Fuel offers the ability to perform post-deployment checks to verify operations. Here we discuss how to run these tests; see Details of Health Checks for details about the steps these tests take.

Part of Fuel's goal is to provide easily accessible status information about the most commonly used components and the most recently performed actions. To perform these checks you will use Sanity and Functional checks, as described below:

Sanity Checks: Reveal whether the overall system is functional. If these tests fail, you probably need to restart some services to operate OpenStack.
Functional Checks: Dive in a little deeper and reveal networking, system-requirements, functionality issues.

Sanity Checks will likely be the point on which the success of your deployment pivots, but it is critical to pay close attention to all information collected from theses tests. Another way to look at these tests is by their names.

Benefits

Using post-deployment checks helps you identify potential issues which may impact the health of a deployed system.
All post-deployment checks provide detailed descriptions about failed operations and tell you which component or components are not working properly.
Performing these checks manually would consumed a great deal of time, but it only take a few minutes to run the full suite of tests from the Fuel console.
Aside from verifying that everything is working correctly, the process also determines how quickly your system works.
Post-deployment checks continue to be useful after you initially deploy your environment. For example, after sizable changes are made in the environment, you can use the checks to determine if any new failure points have been introduced.

Running Post-Deployment Checks

Now, let`s take a closer look on what should be done to execute the tests and to understand if something is wrong with your OpenStack environment.

As you can see on the image above, the Fuel UI now contains a Health Check tab, indicated by the Heart icon.

All of the post-deployment checks are displayed on this tab. If your deployment was successful, you will see a list of tests this show a green Thumbs Up in the last column. The Thumb indicates the status of the component. If you see a detailed message and a Thumbs Down, that component has failed in some manner, and the details will indicate where the failure was detected. All tests can be run on different environments, which you select on main page of Fuel UI. You can run checks in parallel on different environments.

Each test contains information on its estimated and actual duration. There is information included about test processing time from in-house testing and indicate this in each test. Note that average times are listed from the slowest to the fastest systems tested, so your results may vary.

Once a test is complete, the results will appear in the Status column. If there was an error during the test, the you will see the error message below the test name. To assist in troubleshooting, the test scenario is displayed under the failure message and the failed step is highlighted. You will find more detailed information on these tests later in this section.

An actual test run looks like this:

What To Do When a Test Fails

If a test fails, there are several ways to investigate the problem. You may prefer to start in Fuel UI, since its feedback is directly related to the health of the deployment. To do so, start by checking the following:

Under the Health Check tab
In the OpenStack Dashboard
In the test execution logs (in Environment Logs)
In the individual OpenStack components' logs

Certainly there are many different conditions that can lead to system breakdowns, but there are some simple items that can be examined before you start digging deeply. The most common issues include:

Not all OpenStack services are running
Some defined quota has been exceeded
Something has broken in the network configuration
A general lack of resources (memory/disk space)

The first thing to be done is to ensure all OpenStack services are up and running. To do this, you can run the sanity test set or execute the following command on your Controller node:

nova-manage service list

If any service is off (has “XXX” status), you can restart it using this command:

service openstack-<service name> restart

If all services are on, but you`re still experiencing some issues, you can gather information from OpenStack Dashboard (exceeded number of instances, fixed IPs, etc). You may also read the logs generated by tests which are stored in Logs -> Fuel Master -> Health Check and check if any operation is in ERROR status. If it looks like the last item, you may have underprovisioned our environment and should check your math and your project requirements.

High Availability checks

The following tests are available to check High Availability (HA):

Check data replication over MySQL
Check amount of tables in OS databases is the same on each node
Check Galera environment state
RabbitMQ availability
RabbitMQ replication

Platform Tests Description

Platform tests verify basic functionality of Heat, Sahara and Murano services. Typically, preparation for Sahara testing is a lengthy process that involves several manual configuration steps.

See the following:

Installing Sahara

To install Sahara and run Hadoop in your OpenStack environment:

Select the "Install Sahara" check box on the Fuel UI screen or in the environment settings.
Download the appropriate pre-built image for Hadoop and upload it into Glance:

See the Sahara Images page to find a download link.
Register the image in the Sahara Image Registry. This can be done in Project -> Data processing -> Image Registry. Here click on 'Register Image' button. Specify the username appropriate to the image you use. Usernames can be found in Sahara Images. Specify plugin and version corresponding to the image from the dropdowns and add the required tags with 'Add plugin tags' button.
Ensure that you have an adequate pool of floating IPs available:

If you are running Neutron networking or Nova-Network with auto_assign_floating_ip parameter set to false, you will need to provide a floating IP pool in each Node Group Template you define.

If you are running Nova-Network with auto_assign_floating_ip parameter set to true, you do not have to specify floating IP pool in Node Group Templates; the floating IPs are automatically assigned to each Hadoop cluster member.

For information about planning your Sahara deployment, see Planning a Sahara Deployment.
For a list of prebuilt images, see Sahara Images.
For advanced information about running and testing Sahara, see Sahara Deployment.

Upgrading and Updating from Earlier Releases

If you have a functional Mirantis OpenStack 6.0 environment, you can upgrade the Fuel Master node to version 6.1 but leave your current environments in place.

Upgrade Fuel from Earlier Versions

If you are running Fuel 4.x or earlier, you cannot upgrade to 6.1.
If you are running Fuel 5.x, you cannot upgrade directly to 6.1. You will need to upgrade from 5.x to 6.0 first, and then you can upgrade to 6.1.
If you are running Fuel 6.0, you can upgrade to Fuel 6.1

Fuel 6.1 console can manage your existing 6.x OpenStack environment(s) and create and manage new 6.1 OpenStack environments.

The following table summarizes the available progressions for upgrades of the Fuel Master Node:

Initial Fuel version	Fuel is upgraded to	Upgraded Fuel can manage
5.0	5.1, then to 5.1.1, then to 6.0	2014.1-5.0 2014.1.1-5.0.2 2014.1.1-5.1 2014.1.3-5.1.1 2014.2-6.0
5.0	5.0.1, then to 5.1, then to 5.1.1 then to 6.0	2014.1-5.0 2014.1.1-5.0.1 2014.1.1-5.0.2 2014.1.1-5.1 2014.1.3-5.1.1 2014.2-6.0
5.0.1	5.1, then to 5.1.1 then to 6.0	2014.1.1-5.0.1 2014.1.1-5.0.2 2014.1.1-5.1 2014.1.3-5.1.1 2014.2-6.0
5.1	5.1.1, then to 6.0	2014.1.1-5.1 2014.1.3-5.1.1 2014.2-6.0
6.0	6.1	2014.2-6.0 2014.2.2-6.1

Note the following:

Fuel 6.1 can only deploy 6.1 environments.
Fuel can manage environments that were deployed with 6.0 releases, assuming that you created the environment with the earlier release and upgraded the Fuel Master node rather than doing a fresh install. For a list of OpenStack releases and versions that your Fuel Master node can manage, click on the "Releases" tab at the top of your Fuel home page.
If you do a fresh install of Fuel 6.1, you cannot manage environments deployed with earlier Fuel versions.
If you are running Fuel 4.x or earlier, you cannot upgrade Fuel but must install Mirantis OpenStack 6.1 and redeploy your environment to use the new release.

The following procedure upgrades the Fuel software that runs on the Fuel Master node. See How Fuel upgrade works for information about how the upgrade process is implemented.

To upgrade the Fuel Master Node:

Be sure that no installations are in progress in the environment.
Download the upgrade tarball by going to http://software.mirantis.com. Click Download Now and on your right select Mirantis OpenStack Upgrade. Put the downloaded file to a location on the Fuel Master Node that has at least 2 GB of free space for the archive, and additional 6 GB on the partition where it will be unpacked.

If your Fuel Master Node does not have an Internet connection, you may need to download this file to a local system and then transfer the file to the Fuel Master using scp or an SSH client.
Extract the tarball contents:
```
cd /var/tmp  # Use the directory where the tarball is located
lrzuntar filename.tar.lrz
```
Warning

The Fuel Master node must have at least 2 GB of RAM in order for lrzip to decompress the upgrade archive. See Fuel Master Node Hardware Recommendations for a full list of hardware requirements for the Master node.

If your Fuel Master node does not have enough RAM to decompress the archive, you can unpack it with lrzuntar or its equivalent on another system, then transfer the extracted files to the Master node.
Run the upgrade script from that same directory and supply the Fuel administrator (admin user) password:
```
./upgrade.sh --password <password>
```
If you do not specify the password here, you will be prompted for the password. See Fuel Access Control for background information.

The upgrade process can take 30-60 minutes. Some operations (such as uploading images) take several minutes; the listing of updated files may slow down, but this does not mean that the upgrade process has hung.

When the upgrade is complete, the following messages will appear under the Releases tab in the Fuel web UI:

New release available: Juno on Ubuntu 14.04.1 (2014.2.2-6.1)
New release available: Juno on CentOS 6.5 (2014.2.2-6.1)

Role operations

Role object

Beginning with Fuel 6.1, you can create, update or delete roles using Nailgun REST API and Fuel Client.

For Fuel CLI command reference, see Role operations section.

This section provides the Controller role example:

id: 9
meta:
  conflicts:
  - compute
  description: The controller initiates orchestration activities and provides an external
    API.  Other components like Glance (image storage), Keystone (identity management),
    Horizon (OpenStack dashboard) and Nova-Scheduler are installed on the controller
    as well.
  has_primary: true
  limits:
    min: 1
    overrides:
    - condition: cluster:mode == 'multinode'
      max: 1
      message: Multi-node environment can not have more than one controller node.
    - condition: cluster:mode == 'ha_compact'
      message: At least 3 controller nodes are recommended for HA deployment.
      recommended: 3
  name: Controller
  update_required:
  - compute
  - cinder
name: controller
volumes_roles_mapping:
    - allocate_size: min
      id: os
    - allocate_size: all
      id: image

The following fields are mandatory:

name: controller
meta:
  name: Controller
  description: Description goes here

# at least one volume is required
volumes_roles_mapping:
  - allocate_size: min
    id: os

Primary behaviour for node can be enabled with has_primary: true option. If this option is set to during orchestration, you will be able to assign separate tasks for primary-controller and controller.

Selasa, 20 September 2016

Mirantis Openstack manual

User Guide

Introduction to the User Guide

Confirm hardware

Download and Install Fuel

Create the Installation Media

Create a USB drive to store the Fuel ISO image on a UNIX system

Install Fuel Master Node

Changing PXE Network Parameters During Installation

Fuel Setup

Network Setup

PXE Setup

DNS & Hostname

Time sync with NTP

Root password

Shell login

Fuel login

Quit Setup

Boot the Fuel Master Node

Boot the node servers

Install Fuel plugins

Overview

Validation

Installation steps

Create a new OpenStack environment

Launch Wizard to Create New Environment

Change Fuel Password

Approve Statistics Gathering

Name Environment and Choose Distribution

High-availability (HA) mode

Hypervisor

Network service

Storage backend for Cinder and Glance

Related projects

Complete the creation of your environment

Configure your Environment

Add nodes to the environment

Assign a role or roles to each node server

Disk partitioning

Network settings

Neutron network settings

Nova-network settings

Setting NIC bonding (NIC aggregation)

Mapping logical networks to physical interfaces on servers

Verify Networks

Settings tab

Access permissions for Horizon

Provision Method

Repositories

Services included in the environment

Common settings

Setting debug level for the environment

Choose the Compute Node Scheduler

Choose image format

Public Key

Setting initial kernel parameters for target nodes

Configuring syslog

Mellanox Neutron components

Storage

Resetting the Zabbix password

Deploy Changes

Stopping Deployment from Web UI

Resetting environment after deployment

Next Steps

Post-Deployment Check

Benefits

Running Post-Deployment Checks

What To Do When a Test Fails

High Availability checks

Platform Tests Description

Installing Sahara

Upgrading and Updating from Earlier Releases

Upgrade Fuel from Earlier Versions

Role operations

Role object

Tidak ada komentar:

Posting Komentar