Move Fuel Installation Guide to fuel-docs
Move the Fuel Installation Guide to fuel-docs. Created the userdocs foler. Change-Id: Ie7273da30c486033b9ccc7cc258719e73a9a8ae9
This commit is contained in:
Svetlana Karslioglu
parent
338a5020ce
commit
42ace6e5d9
Binary file not shown.
|
After Width: | Height: | Size: 58 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 83 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 114 KiB |
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 20 KiB |
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 20 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 81 KiB |
|
|
@ -0,0 +1,50 @@
|
|||
#embeddedFonts: [ [ "PT Sans" ], [ "PT Mono" ], [ "PT Serif" ] ]
|
||||
# ["PT_Sans-CaptionBold.ttf", "PT_Sans-Bold.ttf", PT_Sans-Italic.ttf, PTF75F.ttf, PT_Sans-BoldItalic.ttf,
|
||||
# PT_Sans-Narrow.ttf, PTF76F.ttf, PT_Sans-Bold_0.ttf, PT_Sans-NarrowBold.ttf,
|
||||
# PTZ55F.ttf, PT_Sans-Caption.ttf, PT_Sans-Regular.ttf]
|
||||
|
||||
fontsAlias:
|
||||
stdBold: PT Sans Bold
|
||||
stdBoldItalic: PT Sans Bold Italic
|
||||
stdFont: PT Sans
|
||||
stdItalic: PT Sans Italic
|
||||
stdMono: PT Mono
|
||||
stdMonoBold: PT Mono Bold
|
||||
stdMonoBoldItalic: PT Mono Bold
|
||||
stdMonoItalic: PT Mono
|
||||
stdSans: PT Sans
|
||||
stdSansBold: PT Sans Bold
|
||||
stdSansBoldItalic: PT Sans BoldItalic
|
||||
stdSansItalic: PT Sans Italic
|
||||
stdSerif: PT Serif
|
||||
|
||||
pageSetup:
|
||||
firstTemplate: coverPage
|
||||
# size: LETTER
|
||||
|
||||
pageTemplates:
|
||||
coverPage:
|
||||
frames: []
|
||||
[0cm, 0cm, 100%, 100%]
|
||||
background : _images/title-page.png
|
||||
showHeader : false
|
||||
showFooter : false
|
||||
oneColumn:
|
||||
frames: []
|
||||
[0cm, 0cm, 100%, 100%]
|
||||
showHeader : true
|
||||
showFooter : true
|
||||
|
||||
styles:
|
||||
seealso:
|
||||
backColor: transparent
|
||||
borderColor: transparent
|
||||
parent: admonition
|
||||
|
||||
seealso-heading:
|
||||
parent: heading
|
||||
fontName: PT Sans
|
||||
fontSize: 150%
|
||||
keepWithNext: true
|
||||
spaceBefore: 0
|
||||
spaceAfter: 10
|
||||
|
|
@ -92,3 +92,6 @@ pdf_use_numbered_links = False
|
|||
|
||||
# Background images fitting mode
|
||||
pdf_fit_background_mode = 'scale'
|
||||
pdf_stylesheets = ['letter', 'fuel']
|
||||
pdf_style_path = ['_templates']
|
||||
|
||||
|
|
|
|||
11
conf.py
11
conf.py
|
|
@ -38,6 +38,9 @@ extensions = [
|
|||
'rst2pdf.pdfbuilder'
|
||||
]
|
||||
|
||||
# Add any paths that contain templates here, relative to this directory.
|
||||
# templates_path = ['_templates']
|
||||
|
||||
# The suffix of source filenames.
|
||||
source_suffix = '.rst'
|
||||
|
||||
|
|
@ -49,16 +52,16 @@ master_doc = 'index'
|
|||
|
||||
# General information about the project.
|
||||
project = u'Fuel'
|
||||
copyright = u'2012-2014, Mirantis'
|
||||
copyright = u'2012-2016, Mirantis'
|
||||
|
||||
# The version info for the project you're documenting, acts as replacement for
|
||||
# |version| and |release|, also used in various other places throughout the
|
||||
# built documents.
|
||||
#
|
||||
# The short X.Y version.
|
||||
version = '0'
|
||||
version = '8.0'
|
||||
# The full version, including alpha/beta/rc tags.
|
||||
release = ''
|
||||
release = '8.0'
|
||||
|
||||
# The language for content autogenerated by Sphinx. Refer to documentation
|
||||
# for a list of supported languages.
|
||||
|
|
@ -104,7 +107,7 @@ html_theme = 'openstackdocs'
|
|||
|
||||
# Theme options are theme-specific and customize the look and feel of a theme
|
||||
# documentation.
|
||||
#html_theme_options = {}
|
||||
# html_theme_options =
|
||||
|
||||
# Add any paths that contain custom themes here, relative to this directory.
|
||||
html_theme_path = [openstackdocstheme.get_html_theme_path()]
|
||||
|
|
|
|||
|
|
@ -1,11 +1,10 @@
|
|||
.. _develop:
|
||||
|
||||
Development Documentation
|
||||
=========================
|
||||
Developer Guide
|
||||
===============
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 3
|
||||
:numbered:
|
||||
|
||||
develop/architecture
|
||||
develop/sequence
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
Devops Guide
|
||||
DevOps Guide
|
||||
============
|
||||
|
||||
Introduction
|
||||
|
|
|
|||
|
|
@ -0,0 +1,14 @@
|
|||
.. _infra:
|
||||
|
||||
Fuel Infra configuration
|
||||
========================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
infra/overview
|
||||
infra/jenkins_master_deployment
|
||||
infra/jenkins_slave_deployment
|
||||
infra/puppet_master_deployment
|
||||
infra/zabbix_server_deployment
|
||||
infra/seed_server_deployment
|
||||
|
|
@ -1,5 +1,5 @@
|
|||
Jenkins Slave
|
||||
=============
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
The Jenkins Slave is a machine that is set up to run build projects scheduled
|
||||
from the master. Slave runs a dedicated program called a ``slave agent``
|
||||
|
|
@ -98,4 +98,4 @@ To deploy Jenkins slave, complete the following steps:
|
|||
--server puppet-master.test.local --waitforcert 60
|
||||
|
||||
The last action requests the client's certificate. To continue the puppet run,
|
||||
the certificate should be signed from the Puppet Master.
|
||||
the certificate should be signed from the Puppet Master.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
.. _puppet_master:
|
||||
|
||||
Puppet Master
|
||||
=============
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
Puppet is a tool which provides ability to manage configuration of systems in an
|
||||
automatic way using the declarative language. The so called 'manifests' are
|
||||
|
|
@ -36,9 +38,9 @@ The script does the following:
|
|||
|
||||
When script finishes successfully, the Puppet Master installation is completed.
|
||||
|
||||
-----------
|
||||
|
||||
Using Hiera
|
||||
-----------
|
||||
~~~~~~~~~~~
|
||||
|
||||
Puppet can use Hiera to look for data. Hiera allows to override manifest
|
||||
parameter values during the deployment, thus it is possible to create
|
||||
|
|
|
|||
|
|
@ -5,7 +5,6 @@ Packaging
|
|||
|
||||
.. toctree::
|
||||
:maxdepth: 3
|
||||
:numbered:
|
||||
|
||||
packaging/package_versions
|
||||
packaging/perestroika
|
||||
packaging/perestroika
|
||||
|
|
|
|||
|
|
@ -1,7 +0,0 @@
|
|||
.. _user:
|
||||
|
||||
User Guide
|
||||
==========
|
||||
|
||||
User guide has been moved to `docs.mirantis.com <http://docs.mirantis.com/>`_.
|
||||
If you want to contribute, checkout the sources from `github <https://github.com/openstack/fuel-docs.git>`_.
|
||||
39
index.rst
39
index.rst
|
|
@ -1,20 +1,39 @@
|
|||
.. _contents:
|
||||
|
||||
Table of contents
|
||||
=================
|
||||
Welcome to Fuel Documentation!
|
||||
==============================
|
||||
|
||||
Fuel is an open-source tool that enables you to easily and quickly
|
||||
provision multiple OpenStack environments, as well as manage your environments
|
||||
after deployment. You can install Fuel and deploy your OpenStack environment
|
||||
on a virtual platform such as Oracle VirtualBox or VMware vSphere for testing
|
||||
purposes, as well as on bare-metal hardware for production.
|
||||
|
||||
This page provides Fuel developer and user documentation.
|
||||
|
||||
User documentation
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Learn how to install and configure Fuel, as well as how to deploy your
|
||||
OpenStack environments and manage them after deployment.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 4
|
||||
:numbered:
|
||||
:maxdepth: 1
|
||||
|
||||
userdocs/fuel-install-guide
|
||||
|
||||
Developer documentation
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Learn about Fuel internals, software architecture, and how Fuel components
|
||||
interact with each other.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
devdocs/develop
|
||||
devdocs/user
|
||||
devdocs/devops
|
||||
devdocs/buildsystem
|
||||
devdocs/infra/jenkins_master_deployment
|
||||
devdocs/infra/jenkins_slave_deployment
|
||||
devdocs/infra/overview
|
||||
devdocs/infra/puppet_master_deployment
|
||||
devdocs/infra/seed_server_deployment
|
||||
devdocs/infra/zabbix_server_deployment
|
||||
devdocs/infra
|
||||
devdocs/packaging
|
||||
|
|
|
|||
|
|
@ -0,0 +1,17 @@
|
|||
.. _fuel-install-guide:
|
||||
|
||||
=======================
|
||||
Fuel Installation Guide
|
||||
=======================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 3
|
||||
|
||||
fuel-install-guide/intro_fuel_install_intro
|
||||
fuel-install-guide/sysreq_intro
|
||||
fuel-install-guide/install_install_fuel
|
||||
fuel-install-guide/bootstrap_intro
|
||||
fuel-install-guide/plugins_intro
|
||||
fuel-install-guide/vsphere_intro
|
||||
fuel-install-guide/upgrade_intro
|
||||
fuel-install-guide/preinstall_intro
|
||||
|
|
@ -0,0 +1,179 @@
|
|||
.. _bootstrap_add_package:
|
||||
|
||||
Build a bootstrap image with an additional package
|
||||
--------------------------------------------------
|
||||
|
||||
You can install any custom package from the default repository or
|
||||
the connected external repository through the ``fuel-bootstrap`` builder script.
|
||||
|
||||
**Example 1: Installation of the ``strace`` package from the default repository**
|
||||
|
||||
#. Build the bootstrap:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ fuel-bootstrap build --package 'strace' --label 'bootstrap_with_strace' \
|
||||
--output-dir ~/example1/
|
||||
|
||||
**System response:**
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
...Building process...
|
||||
Building initramfs
|
||||
Building squashfs
|
||||
...
|
||||
Bootstrap image a778efad-88ca-41fe-b592-f02101c11d22 has been built: /root/example1/a778efad-88ca-41fe-b592-f02101c11d22.tar.gz
|
||||
|
||||
|
||||
#. After the build process is completed, you can import and activate the new bootstrap image:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ fuel-bootstrap import ~/example1/a778efad-88ca-41fe-b592-f02101c11d22.tar.gz --activate
|
||||
|
||||
#. Verify that the bootsrtap image has been activated:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ fuel-bootstrap list |grep active
|
||||
|
||||
**System response:**
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
| a778efad-88ca-41fe-b592-f02101c11d22 | bootstrap_with_strace | active |
|
||||
|
||||
#. Reboot the discovered node:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ ssh 10.109.0.3 reboot
|
||||
|
||||
#. Verify that the new bootstrap image is loaded on the discovered node:
|
||||
|
||||
#. Verify that the ``runtime_uuid`` value of the activated bootstrap image
|
||||
has been updated in the ``nailgun-agent`` configuration file:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# cat /etc/nailgun-agent/config.yaml
|
||||
|
||||
**System response:**
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
{runtime_uuid: a778efad-88ca-41fe-b592-f02101c11d22}
|
||||
|
||||
#. Verify that the new package has been installed:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# dpkg -l |grep strace
|
||||
|
||||
**System response:**
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
ii strace 4.8-1ubuntu5 amd64 A system call tracer
|
||||
|
||||
|
||||
**Example 2: Installation of the ``nginx`` package using a custom repository**
|
||||
|
||||
#. Add the ``nginx`` repository to the ``fuel_bootstrap_cli.yaml`` file:
|
||||
|
||||
#. Open the fuel_bootstrap_cli.yaml file for editing:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ vim /etc/fuel-bootstrap-cli/fuel_bootstrap_cli.yaml
|
||||
|
||||
#. Add the following text:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
...
|
||||
repos:
|
||||
- name: ubuntu-0
|
||||
...
|
||||
- name: ubuntu-1
|
||||
...
|
||||
- name: custom_user_repo
|
||||
priority: 1001
|
||||
section: "nginx"
|
||||
suite: trusty
|
||||
type: deb
|
||||
uri: "http://nginx.org/packages/ubuntu"
|
||||
...
|
||||
|
||||
.. warning::
|
||||
|
||||
The first repository must point to the upstream mirror.
|
||||
|
||||
.. warning::
|
||||
|
||||
Use priorities higher than 1000 to force the installation
|
||||
of an old version of a package, when other repositories
|
||||
have newer versions of the same package or a newer version
|
||||
of the package is already installed on the system.
|
||||
You can use the force installation in case of a regression
|
||||
caused by the newer version of a package.
|
||||
Find more information about apt-pinning in
|
||||
`Debian Manuals <https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_tweaking_candidate_version>`_.
|
||||
|
||||
#. Build the bootstrap image:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ fuel-bootstrap --verbose --debug build --label 'with_nginx_repo_package' --package nginx --activate
|
||||
|
||||
**System response:**
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
...
|
||||
Bootstrap image e295a410-2605-4ddf-a967-c3d638d901bc has been built:
|
||||
...
|
||||
Bootstrap image e295a410-2605-4ddf-a967-c3d638d901bc has been activated.
|
||||
...
|
||||
|
||||
#. After the build process is completed, reboot the discovered node.
|
||||
|
||||
#. Verify that the new package has been installed:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# dpkg -l |grep nginx
|
||||
|
||||
**System response:**
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
ii nginx 1.8.1-1~trusty amd64 high performance web server
|
||||
|
||||
#. View the status of the packageL
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# apt-cache show nginx
|
||||
|
||||
**System response:**
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
Package: nginx
|
||||
Status: install ok installed
|
||||
...
|
||||
|
||||
#. Verify that the ``runtime_uuid`` value of the activated bootstrap image
|
||||
has been updated in the ``nailgun-agent`` configuration file:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# cat /etc/nailgun-agent/config.yaml
|
||||
|
||||
**System response:**
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
{runtime_uuid: e295a410-2605-4ddf-a967-c3d638d901bc}
|
||||
|
|
@ -0,0 +1,64 @@
|
|||
.. _bootstrap_builder:
|
||||
|
||||
Overview of the Fuel bootstrap builder
|
||||
--------------------------------------
|
||||
|
||||
The bootstrap generator creates bootstrap images for the Fuel Master node
|
||||
that Fuel will use to boot the Fuel Slave nodes. The bootstrap
|
||||
generator uses default configurations, however, you
|
||||
can modify these settings.
|
||||
|
||||
You can customize a Fuel bootstrap image using one of the following options:
|
||||
|
||||
* Set additional packages for the installation.
|
||||
* Copy custom files into the root bootstrap.
|
||||
* Run a user script at the bootstrap file system during the image
|
||||
creation.
|
||||
|
||||
|
||||
You can configure Fuel bootstrap images using the ``fuel-bootstrap`` command:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
usage: fuel-bootstrap [--version] [-v] [--log-file LOG_FILE] [-q] [-h]
|
||||
[--debug]
|
||||
|
||||
|
||||
.. list-table:: **Optional arguments**
|
||||
:widths: 10 25
|
||||
:header-rows: 0
|
||||
|
||||
* - Option
|
||||
- Description
|
||||
* - ``--version``
|
||||
- Shows a program's version number and exits.
|
||||
* - ``-v``, ``--verbose``
|
||||
- Increases a verbosity of output. Can be repeated.
|
||||
* - ``--log-file LOG_FILE``
|
||||
- Specify a file to log output. Disabled by default.
|
||||
* - ``-q``, ``--quiet``
|
||||
- Suppress output except for warnings and errors.
|
||||
* - ``-h``, ``--help``
|
||||
- Shows this help message and exits.
|
||||
* - ``--debug``
|
||||
- Shows tracebacks on errors.
|
||||
|
||||
|
||||
.. list-table:: **Commands to operate with a bootstrap image**
|
||||
:widths: 5 25
|
||||
:header-rows: 0
|
||||
|
||||
* - Command
|
||||
- Description
|
||||
* - ``activate``
|
||||
- Activates the specified bootstrap image.
|
||||
* - ``build``
|
||||
- Builds a new bootstrap image with the specified parameters.
|
||||
* - ``delete``
|
||||
- Deletes the specified bootstrap image from the system.
|
||||
* - ``help``
|
||||
- Print the detailed help information for the corresponding command.
|
||||
* - ``import``
|
||||
- Imports an already created bootstrap image to the system.
|
||||
* - ``list``
|
||||
- Lists all available bootstrap images.
|
||||
|
|
@ -0,0 +1,48 @@
|
|||
.. _bootstrap_container_format:
|
||||
|
||||
The fuel-bootstrap container format
|
||||
-----------------------------------
|
||||
|
||||
To simplify bootstrap sharing and delivery, pack all files required
|
||||
for the bootstrap image in a ``tar.gz`` archive. You can also create and
|
||||
archive manually without using the ``fuel-bootstrap`` script.
|
||||
|
||||
The bootstrap archive must include:
|
||||
|
||||
* ``metadata.yaml`` - a ``.yaml`` file that describes the configuration
|
||||
* ``initrd.img`` - an initial RAM file system
|
||||
* ``vmlinuz`` - a kernel image
|
||||
|
||||
.. warning::
|
||||
|
||||
You cannot modify file names. This limitation is planned to be removed in future releases.
|
||||
|
||||
Optionally, you can add extra files:
|
||||
|
||||
* root.squashfs - a root file system
|
||||
|
||||
Mandatory data fields for ``metadata.yaml`` are:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
extend_kopts : 'key=value net.ifnames=1 debug ignore_loglevel'
|
||||
# kernel command line opts will be extended with Fuel default opts.
|
||||
# But, its also possible to re-write default params - w\o any
|
||||
# guarantee of work.
|
||||
|
||||
uuid: 244782c1-7343-43f7-9ee3-8989c252eb2e
|
||||
# Uuid for identify bootstrap.
|
||||
|
||||
**Generate UUID**
|
||||
|
||||
In the case of the manually built bootstrap you can generate UUID with
|
||||
the following command:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
python -c "import uuid; print str(uuid.uuid4())"
|
||||
|
||||
To connect (discover) and work correctly, ``fuel-bootstrap`` requires
|
||||
runtime system to have installed and properly configured packages.
|
||||
The list of packages is specified in the
|
||||
``/etc/fuel-bootstrap-cli/fuel_bootstrap_cli.yaml`` file.
|
||||
|
|
@ -0,0 +1,80 @@
|
|||
.. _bootstrap_debug:
|
||||
|
||||
Enable advanced debugging
|
||||
-------------------------
|
||||
|
||||
If creating a new bootstrap image results in errors,
|
||||
you can analyze your system by enabling the chroot bootstrap
|
||||
development environment.
|
||||
|
||||
This section provides an example of running bootstrap building
|
||||
in the chroot environment.
|
||||
|
||||
**To enable advanced debugging:**
|
||||
|
||||
.. warning::
|
||||
|
||||
Use for debug purpose only.
|
||||
|
||||
#. Prepare the ``sleep`` script:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ cat /root/sleep.sh
|
||||
#!/bin/bash
|
||||
sleep 99h || true
|
||||
|
||||
#. Start the build process with the ``sleep.sh`` script:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ fuel-bootstrap --verbose --debug build --extra-dir /root/mlnx/mlnx_bootstrap_root/ \
|
||||
--label debug --activate --script /root/sleep.sh
|
||||
|
||||
**System response:**
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
...
|
||||
Copy user-script /root/sleep.sh into chroot:/tmp/tmpdOS3ya.fuel-agent-image
|
||||
Trying to execute command: chroot /tmp/tmpdOS3ya.fuel-agent-image /bin/bash -c /sleep.sh
|
||||
|
||||
The process is sleeping and you can jump into chroot
|
||||
|
||||
The ``sleep.sh`` script delays the start of the building process.
|
||||
Therefore, you can enable the chroot environment.
|
||||
|
||||
#. Enable the chroot environment:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ chroot /tmp/tmpdOS3ya.fuel-agent-image /bin/bash
|
||||
|
||||
#. Fix ``PATH`` difference between CentOS and Ubuntu environmnets:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ export PATH=$PATH:/sbin:/bin
|
||||
|
||||
#. You can now make any changes to the ``bootstrap-dev`` system.
|
||||
|
||||
#. After you apply the required changes, exit the chroot environment.
|
||||
|
||||
#. Terminate the ``sleep`` process:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ [root@nailgun ~]# ps xauf |grep sleep
|
||||
|
||||
**System response:**
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
root 23642 0.0 0.0 9524 1128 pts/14 S+ 17:54 0:00 | \_ /bin/bash /sleep.sh
|
||||
root 23643 0.0 0.0 4340 360 pts/14 S+ 17:54 0:00 | \_ sleep 99h
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ kill -s INT 23643
|
||||
|
||||
After that, the building process will continue as usual.
|
||||
|
|
@ -0,0 +1,33 @@
|
|||
.. _bootstrap_inject_cert:
|
||||
|
||||
Inject custom SSL certificates
|
||||
------------------------------
|
||||
|
||||
You can inject any customization scripts and files inside
|
||||
a bootstrap using ``fuel-bootstrap``.
|
||||
For example, you can add custom certificates to access
|
||||
an https repository.
|
||||
|
||||
** To inject certificate files:**
|
||||
|
||||
#. Add a certificate to the Fuel Master system to provide
|
||||
correct work of debootstrap run on the Fuel Master node:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ update-ca-trust force-enable
|
||||
$ cp cert.crt /etc/pki/ca-trust/source/anchors/
|
||||
$ update-ca-trust extract
|
||||
|
||||
#. Create a directory with the certificate to inject:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ mkdir -p /root/bootstrap_root/usr/local/share/ca-certificates/
|
||||
$ cp cert.crt /root/bootstrap_root/usr/local/share/ca-certificates/
|
||||
|
||||
#. Build the bootstrap:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ fuel-bootstrap build --load-cert --extra-dir /root/bootstrap_root/
|
||||
|
|
@ -0,0 +1,225 @@
|
|||
.. _bootstrap_inject_driver:
|
||||
|
||||
Inject a driver from .deb packages
|
||||
----------------------------------
|
||||
|
||||
When you need to install custom hardware drivers from the official
|
||||
repository, you can inject them into a bootstrap.
|
||||
|
||||
**To install a driver provided as a deb package:**
|
||||
|
||||
Input:
|
||||
|
||||
* ``.deb`` files provided by HW-support
|
||||
Fetched from:
|
||||
http://bgate.mellanox.com/openstack/mellanox_fuel_plugin/8.0/repositories/ubuntu/
|
||||
|
||||
* files to be injected to the bootstrap
|
||||
Fetched from review.
|
||||
|
||||
The ``.deb`` files:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ la -lah /root/mlnx_debs/
|
||||
|
||||
**System response:**
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
-rw-r--r-- 1 root root 13M Jan 21 08:55 cirros-testvm-mellanox-ib_0.3.2-7_amd64.deb
|
||||
-rw-r--r-- 1 root root 13M Jan 21 08:55 cirros-testvm-mellanox_0.3.2-ubuntu3_amd64.deb
|
||||
-rw-r--r-- 1 root root 27K Jan 21 08:55 eswitchd_0.13-1_amd64.deb
|
||||
-rw-r--r-- 1 root root 27K Jan 21 08:55 eswitchd_1.14-3_amd64.deb
|
||||
-rw-r--r-- 1 root root 44K Jan 31 16:08 libibverbs1_1.1.8mlnx1-OFED.3.1.1.0.0_amd64.deb
|
||||
-rw-r--r-- 1 root root 49K Jan 31 16:08 libmlx4-1_1.0.6mlnx1-OFED.3.1.1.0.0_amd64.deb
|
||||
-rw-r--r-- 1 root root 3.7K Jan 21 08:55 mlnx-dnsmasq_2015.1.0-1_all.deb
|
||||
-rw-r--r-- 1 root root 100M Jan 21 08:55 mlnx-ofed-fuel_2.3-2.0.8_amd64.deb
|
||||
-rw-r--r-- 1 root root 193M Jan 21 08:55 mlnx-ofed-fuel_3.1-1.5.7_amd64.deb
|
||||
-rw-r--r-- 1 root root 1.9M Jan 31 16:08 mlnx-ofed-kernel-dkms_3.1-OFED.3.1.1.0.3.1.g9032737_all.deb
|
||||
-rw-r--r-- 1 root root 68K Jan 31 16:08 mlnx-ofed-kernel-utils_3.1-OFED.3.1.1.0.3.1.g9032737_amd64.deb
|
||||
-rw-r--r-- 1 root root 14K Jan 31 16:08 ofed-scripts_3.1-OFED.3.1.1.0.3_amd64.deb
|
||||
-rw-r--r-- 1 root root 18K Jan 21 08:55 python-networking-mlnx_2015.1.2-1_amd64.deb
|
||||
|
||||
The files to be injected to the bootstrap image:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ tree /root/mlnx_files//
|
||||
|
||||
**System response:**
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
|-- mellanox_customize_init.sh
|
||||
`-- mlnx_bootstrap_root
|
||||
|-- etc
|
||||
| `-- modprobe.d
|
||||
| `-- ipoib.conf
|
||||
`-- usr
|
||||
`-- bin
|
||||
`-- init_mlnx.sh
|
||||
|
||||
|
||||
.. warning::
|
||||
|
||||
Injected files and folder should have execute permission
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ find /root/mlnx_files/ -type f -iname *.sh -print | xargs chmod 0755
|
||||
$ find /root/mlnx_files/ -type d -print | xargs chmod 755
|
||||
|
||||
The custom script:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ cat /root/mlnx/mellanox_customize_init.sh
|
||||
|
||||
**System response:**
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
#!/bin/bash
|
||||
|
||||
echo "MLNX add init_mlnx.sh into bootstrap /etc/rc.local"
|
||||
sed -i 's/.*fix-configs.*/$(init_mlnx.sh > \/dev\/null 2>\&1) \& || true\n&/' /etc/rc.local
|
||||
|
||||
|
||||
To push deb packages into the bootstrap, create a new repository on the Fuel Master node
|
||||
and pull the repository to the builder following the steps below:
|
||||
|
||||
#. Prepare a custom repository under ``nailgun`` folder:
|
||||
|
||||
#. Create a fodler for the repository:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ mkdir -p /var/www/nailgun/mlnx_repo/ubuntu
|
||||
|
||||
#. Copy all ``*.deb`` files to the folder:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ cp /root/mlnx_debs/*.deb /var/www/nailgun/mlnx_repo/ubuntu
|
||||
|
||||
#. Run ``dpkg`` tool to create repo-metadata:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ pushd /var/www/nailgun/mlnx_repo/ubuntu/
|
||||
$ dpkg-scanpackages ./ /dev/null | gzip -9c > Packages.gz
|
||||
$ popd
|
||||
|
||||
#. Create a simple ``Release`` stub file:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ echo -e "Origin: user_custom\nLabel: custom\nSuite: user_custom\nCodename: \
|
||||
user_custom\nArchitectures: amd64\nComponents: main\nDescription: custom" \
|
||||
> /var/www/nailgun/mlnx_repo/ubuntu/Release
|
||||
|
||||
|
||||
#. Include the repository to configure the bootstrap builder:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ vim /etc/fuel-bootstrap-cli/fuel_bootstrap_cli.yaml
|
||||
|
||||
**System response:**
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
...
|
||||
repos:
|
||||
...
|
||||
- name: custom_mlnx_repo
|
||||
priority: 1001
|
||||
section: ""
|
||||
suite: ./
|
||||
type: deb
|
||||
uri: "http://<FUEL_MASTER_IP>:8080/mlnx_repo/ubuntu/"
|
||||
|
||||
where ``FUEL_MASTER_IP`` is an IP address of the Fuel Master node.
|
||||
|
||||
|
||||
#. Run the bootstrap builder:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ fuel-bootstrap --verbose --debug build --package mlnx-ofed-kernel-dkms \
|
||||
--package mlnx-ofed-kernel-utils --extra-dir \
|
||||
/root/mlnx/mlnx_bootstrap_root/ --label mlnx-ofed-kernel \
|
||||
--activate --script /root/mlnx/mellanox_customize_init.sh
|
||||
|
||||
**System response:**
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
...
|
||||
Trying to execute command: rsync -rlptDKv /root/mlnx/mlnx_bootstrap_root// /tmp/tmpsJA1Yp.fuel-agent-image/
|
||||
...
|
||||
Trying to execute command: chroot /tmp/tmpsJA1Yp.fuel-agent-image /bin/bash -c /mellanox_customize_init.sh
|
||||
....
|
||||
stdout:MLNX add init_mlnx.sh into bootstrap /etc/rc.local
|
||||
...
|
||||
Setting up mlnx-ofed-kernel-dkms (3.1-OFED.3.1.1.0.3.1.g9032737)
|
||||
...
|
||||
Loading new mlnx-ofed-kernel-3.1 DKMS files
|
||||
...
|
||||
Rsync files from /root/mlnx/mlnx_bootstrap_root/ to: /tmp/tmpIA5Ro8.fuel-agent-image
|
||||
...
|
||||
--- Building bootstrap image END (do_mkbootstrap) ---
|
||||
...
|
||||
Bootstrap image 37369fd8-34c0-444d-a4d1-2f266d586442 has been activated
|
||||
|
||||
|
||||
#. Reboot the affected nodes:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ ssh 10.109.0.3 reboot
|
||||
|
||||
#. Check that the driver has been installed succesfully:
|
||||
|
||||
#. View the information about the installed packages:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# dpkg -l |grep mlnx
|
||||
|
||||
**System response:**
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
ii mlnx-ofed-kernel-dkms 3.1-OFED.3.1.1.0.3.1.g9032737 all DKMS support for mlnxofed kernel modules
|
||||
ii mlnx-ofed-kernel-utils 3.1-OFED.3.1.1.0.3.1.g9032737 amd64 Userspace tools to restart and tune mlnx-ofed kernel modules
|
||||
|
||||
#. View the information about the installed kernel module:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# modinfo mlx4_core
|
||||
|
||||
**System response:**
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
filename: /lib/modules/3.13.0-76-generic/updates/dkms/mlx4_core.ko
|
||||
version: 3.1-1.0.3
|
||||
license: Dual BSD/GPL
|
||||
description: Mellanox ConnectX HCA low-level driver
|
||||
author: Roland Dreier
|
||||
...
|
||||
|
||||
#. View the running process:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# ps xauf |grep init_mlnx.sh
|
||||
|
||||
**System response:**
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
root 3113 0.0 0.0 9600 1492 pts/0 S 13:00 0:00 /bin/bash /usr/bin/init_mlnx.sh
|
||||
|
|
@ -0,0 +1,202 @@
|
|||
.. _bootstrap_install_kernel:
|
||||
|
||||
Install a custom kernel
|
||||
-----------------------
|
||||
|
||||
You can install a custom kernel in a bootstrap image.
|
||||
For example, you can install the latest Ubuntu kernel
|
||||
or an older version of the kernel intended to fix regressions.
|
||||
|
||||
.. warning::
|
||||
|
||||
Non-standard kernels, which were not verified with the Fuel packages,
|
||||
can brake your system.
|
||||
|
||||
Install the latest kernel
|
||||
-------------------------
|
||||
|
||||
To install the latest ``lts-trusty`` kernel, you do not need
|
||||
to make any customization. Simply run the bootstrap builder with
|
||||
the default parameters and the latest ``lts-trusty`` kernel
|
||||
available in the repositories will be fetched.
|
||||
|
||||
**To install the latest kernel:**
|
||||
|
||||
#. Install the kernel different from ``lts-trusty``
|
||||
|
||||
#. Open and edit configuration file adding the new repository:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ vim /etc/fuel-bootstrap-cli/fuel_bootstrap_cli.yaml
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
...
|
||||
- name: wily1
|
||||
priority: 1001
|
||||
section: "main restricted universe multiverse"
|
||||
suite: wily
|
||||
type: deb
|
||||
uri: "http://cz.archive.ubuntu.com/ubuntu/"
|
||||
- name: wily2
|
||||
priority: 1001
|
||||
section: "main restricted universe multiverse"
|
||||
suite: wily-updates
|
||||
type: deb
|
||||
uri: "http://cz.archive.ubuntu.com/ubuntu/"
|
||||
...
|
||||
|
||||
#. Build and activate a bootstrap image specifying a kernel flavor:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ fuel-bootstrap --verbose --debug build --label 'with_wily_kernel' --activate --kernel-flavor linux-image-generic-lts-wily
|
||||
|
||||
#. Reboot the discovered node:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ ssh 10.109.0.3
|
||||
|
||||
#. Verify if the node applied the kernel succesfully:
|
||||
|
||||
#. View infomation about the installed kernel image:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# dpkg -l | grep wily
|
||||
|
||||
**System response:**
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
ii linux-image-generic-lts-wily 4.2.0.27.21 amd64 Generic Linux kernel image
|
||||
|
||||
#. View infomation about the current kernel:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# uname -a
|
||||
|
||||
**System response:**
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
Linux bootstrap 4.2.0-27-generic #32~14.04.1-Ubuntu SMP Fri Jan 22 15:32:26 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
|
||||
|
||||
|
||||
Install an old kernel
|
||||
---------------------
|
||||
|
||||
For code stability, security, or other reasons, you may not want to install
|
||||
the latest kernel as described above.
|
||||
|
||||
.. note::
|
||||
|
||||
Due to a specific logic of ``apt-get upgrade\dist-upgrade`` system,
|
||||
an old kernel cannot be installed as easily as the latest one.
|
||||
|
||||
**To install an old version of kernel:**
|
||||
|
||||
#. Verify the version of ``lts-vivid`` meta-package:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
apt-cache show linux-image-generic-lts-vivid | grep -i Depends
|
||||
|
||||
**Example of system response:**
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
Depends: linux-image-3.19.0-47-generic, linux-image-extra-3.19.0-47-generic, linux-firmware
|
||||
|
||||
#. Prepare a bash script with the kernel version you want to install.
|
||||
For example:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ cat /root/user_script.sh
|
||||
|
||||
**System response:**
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
#!/bin/bash
|
||||
|
||||
echo "START user-script"
|
||||
apt-get remove -y linux-image-generic-lts* linux-image-*
|
||||
apt-get purge -y linux-image-generic-lts* linux-image-*
|
||||
|
||||
rm -f /boot/vmlinuz*
|
||||
rm -f /boot/initrd*
|
||||
|
||||
apt-get install -y linux-image-3.19.0-25-generic linux-image-extra-3.19.0-25-generic
|
||||
echo "END user-script"
|
||||
|
||||
This bash script installs the ``linux-image-3.19.0-25-generic`` kernel.
|
||||
|
||||
#. Build and activate a bootstrap image including the custom script you created before:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ fuel-bootstrap build --verbose --debug --activate --label 'old_kernel' --script /root/user_script.sh
|
||||
|
||||
**System response:**
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
...
|
||||
Copy user-script /root/user_script.sh into chroot:/tmp/tmplGugKE.fuel-agent-image
|
||||
Make user-script /tmp/tmplGugKE.fuel-agent-image/user_script.sh executable
|
||||
Trying to execute command: chroot /tmp/tmplGugKE.fuel-agent-image /bin/bash -c /user_script.sh
|
||||
...
|
||||
Bootstrap image 244782c1-7343-43f7-9ee3-8989c252eb2e has been built
|
||||
...
|
||||
Bootstrap image 244782c1-7343-43f7-9ee3-8989c252eb2e has been activated.
|
||||
|
||||
#. Reboot the discovered node:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ ssh 10.109.0.3
|
||||
|
||||
#. Verify if the node applied the kernel succesfully:
|
||||
|
||||
#. View infomation about the current kernel:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# uname -a
|
||||
|
||||
**System response:**
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
Linux bootstrap 3.19.0-25-generic #26~14.04.1-Ubuntu SMP Fri Jul 24 21:16:20 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
|
||||
|
||||
#. View infomation about the installed kernel image:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# dpkg -l | grep image
|
||||
|
||||
**System response:**
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
ii linux-image-3.19.0-25-generic 3.19.0-25.26~14.04.1 amd64 Linux kernel image for version 3.19.0 on 64 bit x86 SMP
|
||||
ii linux-image-extra-3.19.0-25-generic 3.19.0-25.26~14.04.1 amd64 Linux kernel extra modules for version 3.19.0 on 64 bit x86 SMP
|
||||
|
||||
#. Verify that the ``runtime_uuid`` value of the activated bootstrap image
|
||||
has been updated in the ``nailgun-agent`` configuration file:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# cat /etc/nailgun-agent/config.yaml
|
||||
|
||||
**System response:**
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
{runtime_uuid: 244782c1-7343-43f7-9ee3-8989c252eb2e}
|
||||
|
|
@ -0,0 +1,55 @@
|
|||
.. _bootstrap_select:
|
||||
|
||||
Select a bootstrap image
|
||||
------------------------
|
||||
|
||||
You can select a bootstrap image from the list of available
|
||||
bootstraps and activate it. The discovered nodes will be loaded
|
||||
with a new bootstrap after reboot.
|
||||
|
||||
**To switch between bootstrap images:**
|
||||
|
||||
#. Print the list of available bootstrap images:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# fuel-bootstrap list
|
||||
|
||||
**System response**
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
+--------------------------------------+--------------------------------------+--------+
|
||||
| uuid | label | status |
|
||||
+--------------------------------------+--------------------------------------+--------+
|
||||
| a778efad-88ca-41fe-b592-f02101c11d22 | bs1 | |
|
||||
| 244782c1-7343-43f7-9ee3-8989c252eb2e | bs2 | active |
|
||||
| 2b7fe334-4ef7-4a9d-8fcb-e0d7cc009d0c | 2b7fe334-4ef7-4a9d-8fcb-e0d7cc009d0c | |
|
||||
| centos | deprecated | |
|
||||
+--------------------------------------+--------------------------------------+--------+
|
||||
|
||||
#. Activate a new bootstrap image:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# fuel-bootstrap activate a778efad-88ca-41fe-b592-f02101c11d22
|
||||
|
||||
#. Reboot the affected node:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# fuel nodes
|
||||
|
||||
**System response**
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
+-------------------------------------------------------------------------------------------------------------+
|
||||
|id | status | name | cluster | ip | mac | roles | pending_roles | online |
|
||||
|---|----------|------------------|---------|------------|-------------------|-------|---------------|--------|
|
||||
|1 | discover | Untitled (29:bb) | None | 10.109.0.3 | 64:26:37:0b:29:bb | | | True |
|
||||
+-------------------------------------------------------------------------------------------------------------+
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# ssh 10.109.0.3 reboot
|
||||
|
|
@ -0,0 +1,138 @@
|
|||
.. _bootstrap_troubleshoot:
|
||||
|
||||
Troubleshoot custom bootstrap building
|
||||
--------------------------------------
|
||||
|
||||
**Automatic Fuel deployment has failed**
|
||||
|
||||
Automatic bootstrap image building can fail with one of the
|
||||
following error messages:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
"WARNING: Ubuntu bootstrap build has been skipped.
|
||||
Please build and activate bootstrap manually with CLI command
|
||||
`fuel-bootstrap build --activate`.
|
||||
While you don't activate any bootstrap - new nodes cannot be discovered
|
||||
and added to cluster.
|
||||
For more information please visit
|
||||
https://docs.mirantis.com/openstack/fuel/fuel-master/"
|
||||
|
||||
or
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
WARNING: Failed to build the bootstrap image, see
|
||||
/var/log/fuel-bootstrap-image-build.log
|
||||
for details. Perhaps your Internet connection is broken. Please fix the
|
||||
problem and run `fuel-bootstrap build --activate`.
|
||||
While you don't activate any bootstrap - new nodes cannot be discovered
|
||||
and added to cluster.
|
||||
For more information please visit
|
||||
https://docs.mirantis.com/openstack/fuel/fuel-master/"
|
||||
|
||||
|
||||
You typically receive such error messages when software
|
||||
repositories are unavailable.
|
||||
|
||||
To resolve the issue:
|
||||
|
||||
* If the Fuel Master node has an Internet connection,
|
||||
verify network connectivity to the software repositories.
|
||||
|
||||
* If you use a local repository mirror:
|
||||
|
||||
* Follow the instructions provided in the ``fuel-mirror``
|
||||
utility https://github.com/openstack/fuel-mirror
|
||||
* Additionally, analyze the following log files:
|
||||
|
||||
- ``/var/log/fuel-bootstrap-image-build.log``
|
||||
- ``/var/log/puppet/bootstrap_admin_node.log``
|
||||
|
||||
|
||||
**A node has an old ``cmdline`` or a wrong bootstrap image**
|
||||
|
||||
``fuel-bootstrap`` has a limitation with UX issue.
|
||||
You can not change a bootstrap image on nodes already added
|
||||
to an environment (serialized).
|
||||
This issue relates to the current architecture restriction.
|
||||
|
||||
The problem may occur under the following conditions:
|
||||
|
||||
* You have a deprecated CentOS bootstrap image in the ``active`` state; or
|
||||
you power on nodes before the Fuel Master node is completely deployed
|
||||
when ``ubuntu-bootstrap`` on the Fuel Master node has not been activated yet.
|
||||
|
||||
* You start a node and add it to an OpenStack environment, or
|
||||
you start or reset deployment on an environment, or any other case
|
||||
that triggers Fuel to store a node and create a cobbler system.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
cobbler system report --name default |grep -i Profile
|
||||
|
||||
**System response:**
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
Profile : bootstrap
|
||||
|
||||
* Fuel (Сobbler) creates a system with the CentOS bootstrap image.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ cobbler system report --name node-1
|
||||
|
||||
**System response:**
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
...
|
||||
Profile : bootstrap (centos-bootstrap)
|
||||
...
|
||||
|
||||
* Then, you change the active bootstrap, which makes
|
||||
astute change the cobbler default profile to ``ubuntu-bootstrap``:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ cobbler system report --name default |grep -i Profile
|
||||
|
||||
**System response:**
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
Profile : ubuntu_bootstrap
|
||||
|
||||
But the stored system still use the old bootstrap data.
|
||||
|
||||
**To enable the new bootstarp image:**
|
||||
|
||||
#. Remove the node from db, reboot, and re-discover it
|
||||
|
||||
.. warning::
|
||||
|
||||
All node data will be destroyed!
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# fuel node --node-id 1 --delete-from-db
|
||||
|
||||
#. Manually update the cobbler profile:
|
||||
|
||||
.. note::
|
||||
|
||||
No data will be destroyed.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ cobbler system edit --name node-1 --profile=ubuntu_bootstrap
|
||||
$ cobbler system report --name node-1 |grep Profile
|
||||
|
||||
**System response:**
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
Profile : ubuntu_bootstrap
|
||||
|
||||
#. Reboot the node.
|
||||
|
|
@ -0,0 +1,59 @@
|
|||
.. _bootstrap_view:
|
||||
|
||||
View available bootstraps
|
||||
-------------------------
|
||||
|
||||
You can view bootstrap images available in your system.
|
||||
|
||||
#. Each bootstrap image has a unique ID which identifies it:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ fuel-bootstrap list
|
||||
|
||||
**System response:**
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
+--------------------------------------+--------------------------------------+--------+
|
||||
| uuid | label | status |
|
||||
+--------------------------------------+--------------------------------------+--------+
|
||||
| 2b7fe334-4ef7-4a9d-8fcb-e0d7cc009d0c | 2b7fe334-4ef7-4a9d-8fcb-e0d7cc009d0c | active |
|
||||
| centos | deprecated | |
|
||||
+--------------------------------------+--------------------------------------+--------+
|
||||
|
||||
#. To check, which exactly bootstrap image is currently loaded on a discovered node:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# fuel nodes
|
||||
|
||||
**System response:**
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
id | status | name | cluster | ip | mac | roles | pending_roles | online | group_id
|
||||
---|----------|------------------|---------|------------|-------------------|-------|---------------|--------|---------
|
||||
1 | discover | Untitled (29:bb) | None | 10.109.0.3 | 64:26:37:0b:29:bb | | | True | None
|
||||
|
||||
|
||||
#. Connect to a node by SSH and check the file:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
ssh 10.109.0.3 cat /etc/nailgun-agent/config.yaml
|
||||
|
||||
**System response:**
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
{runtime_uuid: 2b7fe334-4ef7-4a9d-8fcb-e0d7cc009d0c}
|
||||
|
||||
#. You can use Fuel web UI as well:
|
||||
|
||||
* Go to ``Nodes`` tab of your environment.
|
||||
* Locate the node and click on ``gear`` button in front of the node name.
|
||||
* Expand the ``System`` tab and find ``runtime uuid`` record.
|
||||
|
||||
As you can see, Fuel loaded the discovered node with the bootstrap image marked
|
||||
as ``Active`` in the bootstrap list.
|
||||
|
|
@ -0,0 +1,28 @@
|
|||
.. _install_configure_bootstrap:
|
||||
|
||||
Configure a bootstrap image
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
You can build a custom Ubuntu bootstrap image with
|
||||
the Fuel bootstrap builder that Fuel Master will use
|
||||
to boot Fuel Slave nodes.
|
||||
|
||||
You can include additional packages, custom drivers, and even
|
||||
change the default Ubuntu kernel to be deployed on Fuel Slave nodes.
|
||||
|
||||
This section includes the following topics:
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
bootstrap/bootstrap_builder
|
||||
bootstrap/bootstrap_container
|
||||
bootstrap/bootstrap_view
|
||||
bootstrap/bootstrap_select
|
||||
bootstrap/bootstrap_add_package
|
||||
bootstrap/bootstrap_install_kernel
|
||||
bootstrap/bootstrap_inject_cert
|
||||
bootstrap/bootstrap_inject_driver
|
||||
bootstrap/bootstrap_debug
|
||||
bootstrap/bootstrap_troubleshoot
|
||||
|
||||
|
|
@ -0,0 +1,32 @@
|
|||
.. _install_before_you_install_fuel:
|
||||
|
||||
Before you install Fuel
|
||||
-----------------------
|
||||
|
||||
Before you install Fuel, verify that you have completed the following tasks:
|
||||
|
||||
#. Read and complete the tasks described in the following sections:
|
||||
|
||||
* :ref:`intro_install_overview`
|
||||
* :ref:`sysreq_intro`
|
||||
|
||||
#. If you use bare-metal hardware, set up and connect all hardware.
|
||||
#. If you use virtual hardware, configure all required virtual machines,
|
||||
network, and storage parameters.
|
||||
#. Select a workflow:
|
||||
|
||||
* If you install Fuel on a server with an Internet connection, follow this
|
||||
workflow:
|
||||
|
||||
.. image:: /_images/deliverables/d_install_w_internet.png
|
||||
:width: 70%
|
||||
:align: center
|
||||
|
||||
* If you install Fuel on a server without an Internet connection, you must
|
||||
configure a local repository and modify the default Fuel repositories, so
|
||||
that Fuel installs the operating system packages from the local
|
||||
repositories. Therefore, follow this workflow:
|
||||
|
||||
.. image:: /_images/deliverables/d_install_wo_internet.png
|
||||
:width: 70%
|
||||
:align: center
|
||||
|
|
@ -0,0 +1,65 @@
|
|||
.. _install_boot_nodes:
|
||||
|
||||
|
||||
Boot the Fuel Slave nodes
|
||||
-------------------------
|
||||
|
||||
Before you boot the Fuel Slave nodes, verify that you have completed
|
||||
the following tasks:
|
||||
|
||||
#. :ref:`Install the Fuel Master node <install_install_fuel_master_node>`.
|
||||
|
||||
#. If you plan using RAID arrays, configure you RAID-attached devices first.
|
||||
|
||||
#. Configure the network:
|
||||
|
||||
* If you use bare-metal servers, verify that the Fuel Slave nodes are
|
||||
physically connected to the same network as the Fuel Master node.
|
||||
|
||||
* If you use virtual servers, verify that the Fuel Slave nodes
|
||||
are bridged to the same network as the Fuel Master node.
|
||||
The Fuel Master node and the Fuel Slave nodes must be in
|
||||
the same L2 network segment.
|
||||
|
||||
**To boot the Fuel Slave nodes:**
|
||||
|
||||
#. Power on a Fuel Slave node.
|
||||
|
||||
#. Boot the Fuel Slave node through PXE using one of the following options:
|
||||
|
||||
* Modify the boot order in BIOS to PXE boot.
|
||||
* Press the appropriate key to initiate a PXE boot.
|
||||
|
||||
.. warning::
|
||||
|
||||
If the Fuel Slave node has several network interfaces, enable
|
||||
the PXE boot on the interface that is on the same network
|
||||
as Admin (PXE) network on the Fuel Master node.
|
||||
|
||||
#. Repeat the procedure for all the Fuel Slave nodes you will use for your
|
||||
OpenStack environment.
|
||||
|
||||
Boot workflow of a Fuel Slave node
|
||||
----------------------------------
|
||||
|
||||
The boot workflow of a Fuel Slave node does not require any user interaction.
|
||||
For general understanding of the processes that take place in the system when
|
||||
the Fuel Slave node is booting, get acquainted with the boot procedure:
|
||||
|
||||
#. The Fuel Slave node sends out a DHCP discovery request and gets the response
|
||||
from the Fuel Master node that runs the DHCP server.
|
||||
|
||||
#. On receiving the response, the Fuel Slave node fetches the PXELINUX
|
||||
bootloader and the bootstrap image from the Fuel Master node's TFTP
|
||||
server, and boots into it.
|
||||
|
||||
#. On loading the image, the Fuel Slave node reports readiness and
|
||||
configuration to the Fuel Master node.
|
||||
|
||||
The number of discovered Fuel Slave nodes appears in the Fuel web UI.
|
||||
When all nodes boot, you can create an OpenStack environment.
|
||||
|
||||
.. seealso::
|
||||
|
||||
- *Create an OpenStack Environment* in *Fuel User Guide*
|
||||
|
||||
|
|
@ -0,0 +1,79 @@
|
|||
.. _install_change_admin_network_interface:
|
||||
|
||||
Change the Admin (PXE) network interface
|
||||
----------------------------------------
|
||||
|
||||
By default, Fuel assigns ``eth0`` as a network interface for the Admin (PXE)
|
||||
network. If you want to use the default network settings, skip this section.
|
||||
|
||||
However, some environments may require you to configure other network
|
||||
interfaces for the Admin (PXE) network. If you plan to use a network interface
|
||||
that is differnt from the default setting, change it before you install the
|
||||
Fuel Master node.
|
||||
|
||||
.. warning::
|
||||
Do not change the network interface assigned for the Admin (PXE) network
|
||||
after you install the Fuel Master node.
|
||||
|
||||
**To change the Admin (PXE) network interface:**
|
||||
|
||||
#. In the Fuel Setup screen, select **Network Setup**.
|
||||
#. Select ``eth0``.
|
||||
#. Change **Enable interface** to **No**.
|
||||
#. Click **Apply**.
|
||||
|
||||
Fuel disables ``eth0``.
|
||||
|
||||
#. Select a network interface that you want to use for Admin (PXE) network
|
||||
traffic.
|
||||
|
||||
For example: ``eth1``.
|
||||
|
||||
#. Change **Enable interface** to **Yes**.
|
||||
#. Configure network parameters for ``eth1``.
|
||||
|
||||
Default network parameters are:
|
||||
|
||||
* IP address: 10.20.0.2
|
||||
* Netmask: 255.255.255.0
|
||||
* Gateway: 10.20.0.1
|
||||
|
||||
#. Click **Apply**.
|
||||
|
||||
Fuel will now use ``eth1`` as a network interface for the Admin (PXE)
|
||||
network.
|
||||
|
||||
#. In Menu, select **PXE Setup**.
|
||||
#. Set the DHCP pool range and gateway.
|
||||
#. Verify your configuration by clicking **Check**.
|
||||
#. Proceed to :ref:`install_login_fuel_master_node`.
|
||||
|
||||
.. seealso::
|
||||
|
||||
- :ref:`install_configure_a_network_interface_for_fuel_web_ui`
|
||||
|
||||
|
||||
.. _install_configure_a_network_interface_for_fuel_web_ui:
|
||||
|
||||
Configure a network interface for the Fuel web UI
|
||||
-------------------------------------------------
|
||||
|
||||
You can configure a specific network interface through which users will access
|
||||
the Fuel web UI.
|
||||
|
||||
**To configure a network interface for the Fuel web UI:**
|
||||
|
||||
#. In the Fuel Setup screen, select **Network Setup**.
|
||||
#. Select an unassigned network interface.
|
||||
#. Change **Enable interface** to **Yes**.
|
||||
#. Enable DHCP.
|
||||
#. Verify that the IP address, netmask, and gateway fields are empty.
|
||||
#. Click **Apply**.
|
||||
|
||||
Fuel now uses the selected interface for the Fuel web UI.
|
||||
|
||||
#. Proceed to :ref:`install_login_fuel_master_node`.
|
||||
|
||||
.. seealso::
|
||||
|
||||
- :ref:`install_login_fuel_master_node_multiple_nics`
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
.. _install_download_iso:
|
||||
|
||||
Download the ISO image
|
||||
----------------------
|
||||
|
||||
The Fuel ISO image includes Fuel software components, as well as the
|
||||
latest release of OpenStack which is required to create your OpenStack
|
||||
environment. Therefore, if you use Fuel, you do not need to download any
|
||||
additional OpenStack components.
|
||||
|
||||
However, the Fuel ISO does not include the operating system packages. The Fuel
|
||||
Master node dynamically downloads the packages from the configured software
|
||||
repository.
|
||||
|
||||
**To download the ISO image:**
|
||||
|
||||
#. Go to the `Fuel project page <https://www.fuel-infra.org>`_.
|
||||
#. Download the ISO to your computer.
|
||||
#. Proceed to :ref:`install_prepare_install_media`.
|
||||
|
||||
|
|
@ -0,0 +1,32 @@
|
|||
.. _install_install_fuel_master_node:
|
||||
|
||||
Install the Fuel Master node
|
||||
----------------------------
|
||||
|
||||
Before you install the Fuel Master node, complete the steps described in
|
||||
:ref:`Before you install Fuel <install_before_you_install_fuel>`,
|
||||
:ref:`Download the ISO image <install_download_iso>`, and
|
||||
:ref:`Preparing an installation media <install_prepare_install_media>`.
|
||||
|
||||
**To install the Fuel Master node:**
|
||||
|
||||
#. Insert or mount through IPMI (or using any other remote control utility
|
||||
supported by your hardware) the media with the Fuel ISO on the server
|
||||
that will be your Fuel Master node.
|
||||
|
||||
#. Verify that the Fuel installation media is the first device in the boot
|
||||
order.
|
||||
|
||||
#. Power on the server. The `Welcome to Fuel Installer` screen appears.
|
||||
|
||||
#. Select the installation media. If necessary, modify the boot settings by
|
||||
pressing the Tab key to display the loader command line. Using this command
|
||||
line, configure the IP address, default gateway, and DNS server settings of
|
||||
the Fuel Master node.
|
||||
|
||||
#. Proceed to :ref:`Configure network parameters <install_set_up_fuel>`.
|
||||
|
||||
.. note::
|
||||
|
||||
You can install the Fuel Master node on VMware vSphere. For more information,
|
||||
see: :ref:`Before you install Fuel on VMware vSphere <vsphere_intro>`.
|
||||
|
|
@ -0,0 +1,83 @@
|
|||
.. _install_login_fuel_master_node:
|
||||
|
||||
Log in to the Fuel Master node
|
||||
------------------------------
|
||||
|
||||
When Fuel completes the installation of the Fuel Master node, the Fuel Master
|
||||
node boots automatically and the *Welcome to the Fuel server* message displays.
|
||||
The message contains Fuel web UI and Fuel command-line interface default login
|
||||
credentials.
|
||||
|
||||
.. warning::
|
||||
|
||||
Remove the installation media before booting the system.
|
||||
You may damage or delete the entire environment
|
||||
by booting the installation media once again accidentally.
|
||||
This is especially important if you set the boot order
|
||||
so that the USB or DVD drive boots before the hard disk.
|
||||
|
||||
Log in to the Fuel Master node for further configuration using one of
|
||||
the following options:
|
||||
|
||||
* Log in to the Fuel web UI.
|
||||
* Log in to the Fuel CLI.
|
||||
|
||||
You can perform most of the operations in both Fuel web UI and Fuel CLI.
|
||||
However, for your convenience, we recommend that you use the Fuel web UI for
|
||||
initial configuration.
|
||||
|
||||
**To log in to the Fuel web UI:**
|
||||
|
||||
#. In a web browser, type the IP address and port number that you have
|
||||
assigned for the Fuel web UI in :ref:`Set up Fuel <install_set_up_fuel>`.
|
||||
|
||||
Fuel prompts you for the login credentials.
|
||||
|
||||
#. In a web browser, enter the Fuel UI login and password that you have
|
||||
set for the Fuel web UI in :ref:`Set up Fuel <install_set_up_fuel>`.
|
||||
|
||||
If you use the default network settings, use the following values:
|
||||
|
||||
* IP address: ``https://10.20.0.2:8443/``
|
||||
* Fuel UI login: ``admin``
|
||||
* Fuel UI password: ``admin``
|
||||
|
||||
.. note::
|
||||
|
||||
The IP address must be reachable from the machine on which you open
|
||||
the Fuel web UI URL.
|
||||
|
||||
.. warning::
|
||||
|
||||
For security reasons, change the default credentials for
|
||||
the administrator account.
|
||||
|
||||
The Fuel web UI initial screen displays.
|
||||
|
||||
#. Proceed to :ref:`Boot the Fuel Slave nodes <install_boot_nodes>`.
|
||||
|
||||
**To log in to the Fuel CLI:**
|
||||
|
||||
#. In the Fuel Master node console, type the root login and password that you
|
||||
have assigned in :ref:`Set up Fuel <install_set_up_fuel>`.
|
||||
|
||||
If you use the default settings, type the following login credentials:
|
||||
|
||||
* Login: ``root``
|
||||
* Password: ``r00tme``
|
||||
|
||||
You can change the password using the :command:`passwd` command after
|
||||
you log in.
|
||||
|
||||
.. warning::
|
||||
|
||||
For security reasons, change the default credentials for the root
|
||||
account.
|
||||
|
||||
#. Alternatively, connect to the Fuel Master node using SSH.
|
||||
|
||||
#. Proceed to :ref:`Boot the Fuel Slave nodes <install_boot_nodes>`.
|
||||
|
||||
.. seealso::
|
||||
|
||||
- :ref:`Log in to the Fuel Master node with multiple NICs <install_login_fuel_master_node_multiple_nics>`
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
.. _install_login_fuel_master_node_multiple_nics:
|
||||
|
||||
Log in to the Fuel Master node with multiple NICs
|
||||
-------------------------------------------------
|
||||
|
||||
If the server on which the Fuel Master node is installed has more than one
|
||||
network interface card (NIC), you can access the Fuel web UI with a particular
|
||||
NIC.
|
||||
|
||||
**To access the Fuel web UI with a particular NIC:**
|
||||
|
||||
#. Connect the NIC to the appropriate switch.
|
||||
#. On the Fuel Master node, set an IP address for the NIC.
|
||||
#. Use the IP address that you assigned to log in to the Fuel web UI.
|
||||
For example: ``https://IP_YOU_ASSIGN:8443/``
|
||||
|
||||
.. note::
|
||||
|
||||
The tasks above do not change the default administrator network settings.
|
||||
You can access the Fuel web UI using the URL displayed on the Fuel boot
|
||||
screen.
|
||||
|
||||
.. seealso::
|
||||
|
||||
- :ref:`install_login_fuel_master_node`
|
||||
|
||||
|
|
@ -0,0 +1,85 @@
|
|||
.. _install_prepare_install_media:
|
||||
|
||||
Prepare an installation media
|
||||
-----------------------------
|
||||
|
||||
After downloading the :ref:`Fuel ISO image <install_download_iso>`, you must
|
||||
prepare the installation media by mounting the ISO or burning a DVD/USB
|
||||
drive.
|
||||
|
||||
|
||||
.. _install_create_dvd:
|
||||
|
||||
Create a DVD drive
|
||||
------------------
|
||||
|
||||
You can create a DVD with the Fuel ISO to install Fuel on a virtual or
|
||||
bare-metal hardware.
|
||||
|
||||
**To create a DVD drive:**
|
||||
|
||||
#. Select from the following options:
|
||||
|
||||
* For a remote installation, use a remote control utility to mount the
|
||||
ISO image directly to the server's virtual DVD drive. For example:
|
||||
|
||||
* `IPMItool <http://sourceforge.net/projects/ipmitool/>`_
|
||||
* HP Integrated Lights Out (iLO)
|
||||
* Dell iDRAC
|
||||
|
||||
* For a bare-metal installation, burn the ISO image to a DVD drive using any
|
||||
standard software. For example:
|
||||
|
||||
- *Linux*:
|
||||
|
||||
* `Xfburn <https://apps.ubuntu.com/cat/applications/precise/xfburn/>`_
|
||||
* `Brasero <http://www.linuxfromscratch.org/blfs/view/svn/gnome/brasero.html>`_
|
||||
|
||||
- *Mac OS X*:
|
||||
|
||||
* Disk Utility (a commonly pre-installed application)
|
||||
* `Burn <http://burn-osx.sourceforge.net/Pages/English/home.html>`_
|
||||
|
||||
- *Windows*:
|
||||
|
||||
* `ImgBurn <http://www.imgburn.com/>`_
|
||||
* `InfraRecorder <http://infrarecorder.org/>`_
|
||||
|
||||
#. Proceed to the
|
||||
:ref:`Fuel Master node installation <install_install_fuel_master_node>`.
|
||||
|
||||
|
||||
.. _install_create_usb:
|
||||
|
||||
Create a USB drive with the Fuel ISO on a UNIX system
|
||||
-----------------------------------------------------
|
||||
|
||||
After downloading the Fuel ISO image, you can use a USB flash drive to
|
||||
install Fuel on your machine.
|
||||
|
||||
.. note:: Write the Fuel ISO image to the USB drive itself and not to one of
|
||||
its partitions, if any. For example, if you have a USB ``/dev/sdc`` with
|
||||
the ``/dev/sdc1`` and ``/dev/sdc2`` partititions, write the ISO to
|
||||
``/dev/sdc``.
|
||||
|
||||
**To create a USB drive on a UNIX system:**
|
||||
|
||||
#. Plug in a USB drive to your machine.
|
||||
#. Run the following command:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# dd if=/path-to-your-ISO of=/path-to-your-USB
|
||||
|
||||
**Example:**
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# dd if=/home/user/fuel-isos/fuel-7.0.iso of=/dev/sdc
|
||||
|
||||
.. warning:: This operation wipes all the data you have
|
||||
on the USB drive and places a bootable Fuel ISO
|
||||
on it.
|
||||
|
||||
#. Proceed to
|
||||
:ref:`Install the Fuel Master node <install_install_fuel_master_node>`.
|
||||
|
|
@ -0,0 +1,125 @@
|
|||
.. _install_set_up_fuel:
|
||||
|
||||
Set up Fuel
|
||||
-----------
|
||||
|
||||
During installation, Fuel prompts you to access the Fuel setup screen where you
|
||||
can modify the default network and authentication parameters.
|
||||
|
||||
.. image:: /_images/deliverables/scr_fuel_setup.png
|
||||
:width: 60%
|
||||
:align: center
|
||||
|
||||
Typically, you want to modify network settings to meet the requirements of
|
||||
your existing network infrastructure. Also, you must change the default Fuel
|
||||
administrator password. Although you can change some of the network interface
|
||||
settings after you install the Fuel Master node, we recommend that you
|
||||
finalize network configuration before you install the Fuel Master node.
|
||||
|
||||
.. warning::
|
||||
Do not modify settings of the Admin (PXE) network after you deploy the Fuel
|
||||
Master node, because Fuel will lose the ability to PXE boot and manage
|
||||
OpentStack environments.
|
||||
|
||||
If you are installing Fuel for testing purposes, you can keep the default
|
||||
settings and proceed to :ref:`install_install_fuel_master_node`.
|
||||
|
||||
**To set up Fuel:**
|
||||
|
||||
#. Configure the following settings as required:
|
||||
|
||||
+--------------------------------------+----------------------------------+
|
||||
| 1. Change the Fuel administrator | For security purposes, we |
|
||||
| password. | strongly recommend that you |
|
||||
| | change the Fuel administrator |
|
||||
| | password during installation. |
|
||||
+--------------------------------------+----------------------------------+
|
||||
| 2. Modify the network interface | By default, Fuel assigns the |
|
||||
| settings. | following network parameters to |
|
||||
| | the Admin (PXE) network |
|
||||
| | (``eth0``): |
|
||||
| | |
|
||||
| | * Subnetwork: 10.20.0.2/24 |
|
||||
| | * Gateway: 10.20.0.1 |
|
||||
| | |
|
||||
| | Modify these settings |
|
||||
| | according to the requirements of |
|
||||
| | your existing network |
|
||||
| | infrastructure. |
|
||||
+--------------------------------------+----------------------------------+
|
||||
| 3. Configure the Admin (PXE) network | By default, Fuel configures the |
|
||||
| and a DHCP pool for the Fuel Slave| Admin (PXE) network on `eth0` and|
|
||||
| nodes. | configures the following DHP pool|
|
||||
| | settings: |
|
||||
| | |
|
||||
| | * DHCP pool start: 10.20.0.3 |
|
||||
| | * DHCP pool end: 10.20.0.254 |
|
||||
| | * DHCP gateway: 10.20.0.2 |
|
||||
| | |
|
||||
| | Modify these settings as needed. |
|
||||
+--------------------------------------+----------------------------------+
|
||||
| 4. Configure DNS and hostname. | Configure the DNS and hostname |
|
||||
| | settings, if needed. If your Fuel|
|
||||
| | Master node is not connected to |
|
||||
| | the Internet, leave the External |
|
||||
| | DNS field blank. |
|
||||
+--------------------------------------+----------------------------------+
|
||||
| 5. Configure the bootstrap image that| Fuel ISO includes the CentOS |
|
||||
| Fuel will use to discover the Fuel| bootstrap image that Fuel uses |
|
||||
| Slave nodes through PXE. | to discover the Fuel Slave nodes.|
|
||||
| | Although CentOS is the default |
|
||||
| | and preferred option, it may not |
|
||||
| | include drivers for your |
|
||||
| | hardware, therefore, you may want|
|
||||
| | to use the Ubuntu bootstrap image|
|
||||
| | instead. |
|
||||
| | |
|
||||
| | Some organizations may |
|
||||
| | configure the Fuel Master node in|
|
||||
| | a network protected by a |
|
||||
| | firewall, |
|
||||
| | so that the Fuel Master node may |
|
||||
| | not have an access to the |
|
||||
| | Internet. In this case, you can |
|
||||
| | specify a repository located in |
|
||||
| | the accessible network, HTTP or |
|
||||
| | HTTPS, by adding proxy |
|
||||
| | parameters in the Ubuntu |
|
||||
| | repository field. To configure |
|
||||
| | the Ubuntu repository mirror |
|
||||
| | on a local host, use the |
|
||||
| | ``fuel-createmirror`` script |
|
||||
| | shipped with the Fuel ISO. |
|
||||
| | |
|
||||
| | For more information, see: |
|
||||
| | :ref :`Set up local repository`. |
|
||||
+--------------------------------------+----------------------------------+
|
||||
| 6. Configure the network time | To avoid issues with the time |
|
||||
| protocol. | settings inconsistency on the |
|
||||
| | Fuel Master node and other |
|
||||
| | servers in your IT environment, |
|
||||
| | verify that the Fuel Master node |
|
||||
| | uses correct NTP settings. |
|
||||
+--------------------------------------+----------------------------------+
|
||||
| 7. Change the root password. | For security reasons, change the |
|
||||
| | default root password. Fuel will |
|
||||
| | apply this password to all new |
|
||||
| | OpenStack nodes. Existing |
|
||||
| | OpenStack nodes will continue to |
|
||||
| | use the old password. |
|
||||
+--------------------------------------+----------------------------------+
|
||||
| 8. Configure network settings using | You can configure all settings |
|
||||
| shell. | available on the Fuel Setup |
|
||||
| | screen using shell. |
|
||||
| | Particularly, use shell to |
|
||||
| | apply complex network |
|
||||
| | configurations. |
|
||||
+--------------------------------------+----------------------------------+
|
||||
|
||||
2. Proceed to :ref:`install_install_fuel_master_node`.
|
||||
|
||||
.. seealso::
|
||||
|
||||
- :ref:`Configure a network interface for the Fuel web UI
|
||||
<install_configure_a_network_interface_for_fuel_web_ui>`
|
||||
- :ref:`Change the Admin (PXE) network interface <install_change_admin_network_interface>`
|
||||
|
|
@ -0,0 +1,34 @@
|
|||
.. _install_intro:
|
||||
|
||||
Install Fuel
|
||||
============
|
||||
|
||||
This section describes how to install Fuel on virtual or
|
||||
bare-metal hardware. During the installation, you deploy the Fuel Master node
|
||||
on the selected hardware and boot the servers or virtual machines that are
|
||||
dedicated as Fuel Slave nodes. However, you do not install an operating
|
||||
system or OpenStack components on the Fuel Slave nodes just yet. After you
|
||||
deploy the Fuel Master node, you create an OpenStack environment using the
|
||||
Fuel web UI or Fuel CLI. The Fuel Master node provisions the dedicated Fuel
|
||||
Slave nodes with the selected operating system, OpenStack or other
|
||||
components and roles when you deploy an OpenStack environment.
|
||||
|
||||
If you install Fuel on VMware vSphere, see: : ref: `Installing Fuel on VMware¬
|
||||
vSphere`.¬
|
||||
¬
|
||||
If you install Fuel for testing purposes, see: : ref: `Fuel QuickStart Guide`.
|
||||
|
||||
This section includes the following topics:
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
install/install_before_you_install_fuel
|
||||
install/install_download_iso
|
||||
install/install_prepare_install_media
|
||||
install/install_install_fuel_master_node
|
||||
install/install_set_up_fuel
|
||||
install/install_change_network_interface
|
||||
install/install_login_fuel_master_node
|
||||
install/install_login_fuel_master_node_multiple_nics
|
||||
install/install_boot_slave_nodes
|
||||
|
|
@ -0,0 +1,43 @@
|
|||
.. _intro_fuel:
|
||||
|
||||
Introduction to Fuel
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Fuel is an open-source software application that simplifies the deployment of
|
||||
highly available OpenStack environments, as well as enables you to
|
||||
manage your OpenStack environments after deployment.
|
||||
|
||||
Fuel provides a web user interface (WUI), as well as a command-line user
|
||||
interface (CLI) and RESTful API for provisioning, configuration, and
|
||||
management of OpenStack environments. A link to the Horizon OpenStack
|
||||
Dashboard appears in the Fuel web UI after you deploy an OpenStack
|
||||
environment.
|
||||
|
||||
Using Fuel you can:
|
||||
|
||||
- Deploy multiple highly-available OpenStack environments on virtual or bare
|
||||
metal hardware.
|
||||
|
||||
- Configure and verify network configurations.
|
||||
|
||||
- Test interoperability between the OpenStack components.
|
||||
|
||||
- Easily scale your OpenStack environment by adding and removing nodes.
|
||||
|
||||
Fuel architecture includes:
|
||||
|
||||
Fuel Master node
|
||||
A server with the installed Fuel application that performs initial
|
||||
configuration, provisioning, and PXE booting of the Fuel Slave nodes, as
|
||||
well as assigning the IP addresses to the Fuel Slave nodes.
|
||||
|
||||
Fuel Slave node
|
||||
In the Fuel project terminology, a generic term that describes a server that
|
||||
is provisioned by the Fuel Master node. A Fuel Slave node can be a
|
||||
controller, compute, or storage node, among others. These terms are
|
||||
interchangeable with the OpenStack terminology.
|
||||
|
||||
.. seealso::
|
||||
|
||||
- `Fuel Architecture
|
||||
<https://docs.fuel-infra.org/fuel-dev/develop/architecture.html>`_
|
||||
|
|
@ -0,0 +1,35 @@
|
|||
.. _intro_install_overview:
|
||||
|
||||
Overview of the installation process
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Deployment of an OpenStack environment requires extensive planning.
|
||||
To ensure a successful deployment, review and understand the following
|
||||
requirements and sequence of tasks that you must complete.
|
||||
|
||||
#. Plan your OpenStack environment according to the official OpenStack
|
||||
guidelines and :ref:`Planning your environment <intro_planning>`.
|
||||
|
||||
#. Verify that your environment meets the recommendations in
|
||||
:ref:`System requirements <sysreq_intro>`.
|
||||
|
||||
#. Verify your hardware using the
|
||||
:ref:`Hardware checklist <preinstall_chklist_hardware_checklist>`.
|
||||
|
||||
#. Determine whether the server on which you plan to install the Fuel
|
||||
Master node is connected to the Internet.
|
||||
|
||||
* If the server does not have an Internet
|
||||
connection, then you must configure a local repository. For more
|
||||
information, see: :ref:`Set up a local repository <install_set_up_fuel>`.
|
||||
|
||||
#. If you plan to install Fuel on VMware vSphere, verify that your environment
|
||||
meets the :ref:`VMware vSphere prerequisites <vsphere_intro>`
|
||||
|
||||
#. Download and install Fuel as described in :ref:`Install Fuel <install_intro>`
|
||||
or if you are installing on VMware vSphere in
|
||||
:ref:`Install Fuel on VMware vSphere <vsphere_intro>`.
|
||||
|
||||
#. Install the Fuel plug-ins, if needed. See: :ref:`Plug-ins <fuel-plugins>`.
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,33 @@
|
|||
.. _intro_planning:
|
||||
|
||||
Planning your environment
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Before you install Fuel and OpenStack, determine what type of
|
||||
configuration addresses your business needs. You must understand
|
||||
how OpenStack will integrate and communicate with existing components
|
||||
in your IT infrastructure, as well as calculate resources required to process
|
||||
estimated workloads.
|
||||
|
||||
If you are testing Fuel and OpenStack in a lab environment, you can
|
||||
skip the planning and deploy the default configuration. However, for a
|
||||
production environment, you must decide on the following:
|
||||
|
||||
* Network topology and IP address management plan
|
||||
* Storage
|
||||
* Number, type, and flavor of compute, controller, storage, and other nodes
|
||||
* Monitoring facilities
|
||||
* Additional components: Sahara and Murano
|
||||
* Fuel plug-ins
|
||||
|
||||
This guide explains what OpenStack configurations you can deploy using Fuel,
|
||||
as well as briefly describes guidelines and examples on how to plan resources
|
||||
for your environment. However, we recommend that you read `OpenStack
|
||||
Architecture Design Guide <http://docs.openstack.org/arch-design/content/>`__,
|
||||
so you can better estimate your network, storage, and compute requirements.
|
||||
|
||||
.. seealso::
|
||||
|
||||
- :ref:`System requirements <sysreq_intro>`
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,22 @@
|
|||
.. raw:: pdf
|
||||
|
||||
PageBreak oneColumn
|
||||
|
||||
.. _intro_fuel_install:
|
||||
|
||||
Introduction to Fuel Installation
|
||||
=================================
|
||||
|
||||
This section provides an overview of the Fuel installation
|
||||
process. You can install Fuel on a server with an Internet connection or
|
||||
on a server that is isolated from the Internet for security reasons. Depending
|
||||
on your choice, the workflow differs.
|
||||
|
||||
This section includes the following topics:
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 3
|
||||
|
||||
intro/intro_fuel_intro.rst
|
||||
intro/intro_install_overview
|
||||
intro/intro_planning_your_environment
|
||||
|
|
@ -0,0 +1,61 @@
|
|||
.. _plugins_install_plugins:
|
||||
|
||||
|
||||
Install a Fuel plugin
|
||||
---------------------
|
||||
|
||||
The installation procedure is common for all plugins.
|
||||
For more details about the plugin installation,
|
||||
see the corresponding plugin documentation.
|
||||
|
||||
**To install a Fuel plugin:**
|
||||
|
||||
#. Install the Fuel Master node as described in
|
||||
:ref:`Install the Fuel Master node <install_install_fuel_master_node>`.
|
||||
|
||||
#. Boot the Fuel Master node as described in
|
||||
:ref:`Log in to the Fuel Master node <install_login_fuel_master_node>`.
|
||||
|
||||
#. Download a plugin from `Fuel Plugins
|
||||
сatalog <http://stackalytics.com/report/driverlog?project_id=openstack%2Ffuel>`_.
|
||||
|
||||
#. Read a Plugin Guide to learn about prerequisites and limitations.
|
||||
|
||||
#. Define variables with values suitable for your environment to be used
|
||||
during the plugin installation process or replace them in your command
|
||||
line when appropriate.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
export FUEL_PLUGIN_FILE=fuel-plugin.rpm
|
||||
export FUEL_MASTER_NODE=10.20.0.2
|
||||
|
||||
#. Copy the plugin to the Fuel Master node.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
scp ${FUEL_PLUGIN_FILE} root@:${FUEL_MASTER_NODE}:/tmp
|
||||
|
||||
#. Install the plugin by typing:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
ssh root@:${FUEL_MASTER_NODE} "fuel plugins --install /tmp/${FUEL_PLUGIN_FILE}"
|
||||
|
||||
#. Create an OpenStack environment as described in
|
||||
`Create a new OpenStack environment` in the `Fuel User Guide`.
|
||||
|
||||
#. After completing the Create a new OpenStack environment wizard, click
|
||||
:guilabel:`Settings` in the Fuel web UI.
|
||||
|
||||
#. Enable plugin in the Fuel web UI as described in the plugin documentation.
|
||||
|
||||
#. Configure and deploy your environment as described in
|
||||
`Configure a new environment` in the `Fuel User Guide`.
|
||||
|
||||
|
||||
.. seealso::
|
||||
|
||||
- Fuel plugins CLI
|
||||
- `Fuel plugins catalog
|
||||
<http://stackalytics.com/report/driverlog?project_id=openstack%2Ffuel>`__
|
||||
|
|
@ -0,0 +1,47 @@
|
|||
.. _plugins_overview:
|
||||
|
||||
Fuel plugins overview
|
||||
---------------------
|
||||
|
||||
Fuel provides plugins that you can use to extend the functionality
|
||||
of your OpenStack environment and enable Fuel to work with various
|
||||
third-party components and technologies.
|
||||
|
||||
Most of the Fuel plugins are developed by the OpenStack community
|
||||
members, as well as by the companies who support OpenStack.
|
||||
The Fuel plugins are distributed free of charge.
|
||||
|
||||
Fuel currently has the following plugins:
|
||||
|
||||
* Networking plugins
|
||||
Fuel plugins such as Firewall-as-a-Service and VPN-as-a-Service,
|
||||
as well as plugins that enable Fuel to work with enterprise-grade
|
||||
SDN and virtual networking.
|
||||
|
||||
* Operations management plugins
|
||||
Enable Fuel to work with the third-party monitoring tools such as
|
||||
Zabbix and Grafana.
|
||||
|
||||
* Storage plugins
|
||||
Extend Fuel functionality by enabling OpenStack to use enterprise-class
|
||||
storage platforms as a Cinder backend.
|
||||
|
||||
* Compute plugins
|
||||
Extend the Fuel compute functionality. For example, the XenServer plugin
|
||||
enables you to use the XenServer hypervisor as a compute provider.
|
||||
|
||||
.. note::
|
||||
|
||||
You must install all Fuel plugins that affect core Fuel functionality,
|
||||
such as ML2 drivers, SDN, or storage plugins, before you deploy an
|
||||
OpenStack environment. Application-level plugins, such as LMA, Zabbix,
|
||||
and so on can be installed later.
|
||||
|
||||
`Fuel Plugins SDK <https://wiki.openstack.org/wiki/Fuel/Plugins>`__ enables
|
||||
you to develop virtually any plugin that you need to meet your environment
|
||||
prerequisites.
|
||||
|
||||
|
||||
.. seealso::
|
||||
|
||||
- `Fuel Plugins catalog <http://stackalytics.com/report/driverlog?project_id=openstack%2Ffuel>`__
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
.. _plugins_prerequisites:
|
||||
|
||||
Prerequisites
|
||||
-------------
|
||||
|
||||
When planning to deploy an environment with Fuel plugins, consider the
|
||||
following:
|
||||
|
||||
* If you already have an environment that you want to upgrade, see
|
||||
*Upgrade Fuel*.
|
||||
* Install plugin on Fuel 6.1 or later.
|
||||
* Read additional requirements provided by the selected plugin.
|
||||
|
||||
.. seealso::
|
||||
|
||||
- `Fuel plugins catalog
|
||||
<http://stackalytics.com/report/driverlog?project_id=openstack%2Ffuel¬>`__
|
||||
|
|
@ -0,0 +1,29 @@
|
|||
.. _plugins_upgrade_uninstall_plugin:
|
||||
|
||||
|
||||
Uninstall a plugin
|
||||
------------------
|
||||
|
||||
Fuel does not support upgrades for plugins. The old plugin versions
|
||||
may not be compatible with the new version of Fuel. Therefore, you must
|
||||
uninstall the Fuel plugins before upgrading Fuel.
|
||||
|
||||
**To uninstall a plugin:**
|
||||
|
||||
#. Log in to the Fuel Master node CLI.
|
||||
#. Create an ``uninstall.sh`` script with the following content::
|
||||
|
||||
#!/bin/bash
|
||||
set -eux
|
||||
echo uninstall > /tmp/myplugin_uninstall
|
||||
|
||||
where ``myplugin`` is the name of your plugin.
|
||||
|
||||
#. Put the ``uninstall.sh`` script in your plugin folder.
|
||||
#. Type::
|
||||
|
||||
fuel plugins --remove myplugin
|
||||
|
||||
.. seealso::
|
||||
|
||||
- `Fuel Plugin Wiki <https://wiki.openstack.org/wiki/Fuel/Plugins>`_
|
||||
|
|
@ -0,0 +1,25 @@
|
|||
.. _plugins_view_plugins:
|
||||
|
||||
View Fuel plugins
|
||||
-----------------
|
||||
|
||||
You can view the list of installed plugins in the Fuel Web UI, as well as in
|
||||
the Fuel CLI.
|
||||
|
||||
To view the list of installed plugins using the Fuel Web UI, click the
|
||||
:guilabel:`Plugins` button. It is located at the top of the screen at the
|
||||
Fuel level.
|
||||
|
||||
You can find the following information for every plugin:
|
||||
|
||||
* version
|
||||
* description
|
||||
* homepage
|
||||
* authors
|
||||
* licenses
|
||||
* releases
|
||||
|
||||
.. seealso::
|
||||
|
||||
- Fuel plugins CLI
|
||||
|
||||
|
|
@ -0,0 +1,22 @@
|
|||
.. raw:: pdf
|
||||
|
||||
PageBreak oneColumn
|
||||
|
||||
.. _fuel-plugins:
|
||||
|
||||
Fuel Plugins
|
||||
~~~~~~~~~~~~
|
||||
|
||||
You can extend Fuel functionality by installing the plugins
|
||||
that companies and individual contributors develop for Fuel.
|
||||
|
||||
This section includes the following topics:
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 3
|
||||
|
||||
plugins/plugins_overview
|
||||
plugins/plugins_prerequisites
|
||||
plugins/plugins_install_plugins
|
||||
plugins/plugins_view_plugins
|
||||
plugins/plugins_uninstall_upgrade
|
||||
|
|
@ -0,0 +1,62 @@
|
|||
.. index:: Hardware configuration, confirm
|
||||
|
||||
.. _preinstall_chklist_hardware_checklist:
|
||||
|
||||
Hardware checklist
|
||||
------------------
|
||||
|
||||
Before you install the Fuel Master node, verify that you have configured your
|
||||
hardware correctly. If you install Fuel on virtual hardware for testing
|
||||
purposes, skip this section.
|
||||
|
||||
You must configure all items from the list below before you install Fuel.
|
||||
|
||||
**Hardware checklist**
|
||||
|
||||
+--------------------------------------------------------+--------------+
|
||||
| Item to confirm | Status [tick |
|
||||
| | if done] |
|
||||
+========================================================+==============+
|
||||
| The Fuel server has an IPMI or out-of-band management | |
|
||||
| system that you can access. | |
|
||||
+--------------------------------------------------------+--------------+
|
||||
| The Fuel server hardware can boot the Fuel ISO | |
|
||||
| from a DVD, USB flash drive, or IPMI remote media. | |
|
||||
+--------------------------------------------------------+--------------+
|
||||
| The server on which you plan to install the Fuel Master| |
|
||||
| node can access all nodes through the L2 management | |
|
||||
| network. | |
|
||||
+--------------------------------------------------------+--------------+
|
||||
| The Admin (PXE) network does not have a configured DHCP| |
|
||||
| server. Fuel acts as a DHCP server for Fuel Slave | |
|
||||
| nodes configured to boot using PXE. | |
|
||||
+--------------------------------------------------------+--------------+
|
||||
| The Spanning Tree Protocol (STP) is disabled on switch | |
|
||||
| ports connected | |
|
||||
| to the node servers’ ports or the switch ports are set | |
|
||||
| to the edge/portfast mode. The 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. | |
|
||||
+--------------------------------------------------------+--------------+
|
||||
| The switch assigned for the Admin network does not have| |
|
||||
| any tagged VLANs configured. | |
|
||||
+--------------------------------------------------------+--------------+
|
||||
| The node servers are set to network boot using PXE. | |
|
||||
+--------------------------------------------------------+--------------+
|
||||
| The node servers have hardware virtualization | |
|
||||
| enabled in BIOS. | |
|
||||
+--------------------------------------------------------+--------------+
|
||||
| You have a method to reboot node servers (remotely or | |
|
||||
| on-site). | |
|
||||
+--------------------------------------------------------+--------------+
|
||||
| The network equipment supports VLANs. | |
|
||||
+--------------------------------------------------------+--------------+
|
||||
| Your network switches support tagged ports. | |
|
||||
| You need tagged ports in order to | |
|
||||
| use 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). | |
|
||||
+--------------------------------------------------------+--------------+
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
.. raw:: pdf
|
||||
|
||||
PageBreak oneColumn
|
||||
|
||||
.. _preinstall_intro:
|
||||
|
||||
Pre-installation checklists
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Before you install Fuel, verify that you configured your
|
||||
environment for the installation.
|
||||
|
||||
This section includes the following topics:
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 3
|
||||
|
||||
preinstall/preinstall_hardware_checklist
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
.. _sysreq_addtional_components:
|
||||
|
||||
Additional components
|
||||
---------------------
|
||||
|
||||
If you plan to install additional OpenStack programs, see the system
|
||||
requirements for additional components:
|
||||
|
||||
* :ref:`sysreq_ironic_prereq`
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
.. _sysreq_master_node_hardware_recs:
|
||||
|
||||
Fuel Master node hardware requirements
|
||||
--------------------------------------
|
||||
|
||||
When planning hardware for the Fuel Master node, verify that your hardware
|
||||
meets the following minimum requirements:
|
||||
|
||||
For a production environment:
|
||||
|
||||
* Quad-core CPU
|
||||
* 4 GB RAM
|
||||
* 10 Gigabit network port
|
||||
* 128 GB SAS Disk
|
||||
* IPMI access through an independent management network
|
||||
|
||||
For a testing environment:
|
||||
|
||||
* Dual-core CPU
|
||||
* 2 GB RAM
|
||||
* 1 Gigabit network port
|
||||
* 50 GB disk
|
||||
* Physical console access
|
||||
|
|
@ -0,0 +1,21 @@
|
|||
.. _sysreq_fuel_master_node_network_reqs:
|
||||
|
||||
Fuel Master Node network requirements
|
||||
-------------------------------------
|
||||
|
||||
To deploy the Fuel Slave nodes on which you will run your Controller,
|
||||
Compute, Storage or other nodes, the Fuel Master node must have access to the
|
||||
Internet.
|
||||
|
||||
When you deploy the Fuel Slave nodes, the Fuel Master node connects to the
|
||||
preconfigured repositories through the Internet and installs the selected
|
||||
operating system and the OpenStack packages on the nodes.
|
||||
|
||||
For security reasons, you may not want to connect the Fuel Master node to
|
||||
the Internet. In this case, set up a local repository with the required
|
||||
installation packages and configure these repositories on the Fuel Master
|
||||
node.
|
||||
|
||||
.. seealso::
|
||||
|
||||
- :ref:`upgrade_local_repo`
|
||||
|
|
@ -0,0 +1,45 @@
|
|||
.. _sysreq_fuel_slave_node_hw_recs:
|
||||
|
||||
Fuel Slave nodes hardware recommendations
|
||||
-----------------------------------------
|
||||
|
||||
Determining the appropriate hardware for the slave nodes depends on the node
|
||||
type, the workloads that you plan to run on the nodes, and whether you combine
|
||||
different OpenStack components on one node or run them separately. Typically,
|
||||
you need a two-socket server with the CPU, memory, and disk space that meet
|
||||
your project requirements.
|
||||
Read the `OpenStack Architecture Design Guide` for recommendations on how
|
||||
to plan an OpenStack deployment.
|
||||
|
||||
General guidelines for the Fuel Slave nodes:
|
||||
|
||||
* Controller nodes
|
||||
Use at least three controller nodes for high availability.
|
||||
High availability is recommended for all production environments. However,
|
||||
you can start with a single controller node for testing purposes and add
|
||||
more nodes later. The controller nodes must form a quorum. Therefore, for
|
||||
all deployments, the total number of controller nodes must be odd. Further
|
||||
resource scaling depends on your use case and requires extensive assessment
|
||||
of your environment and business needs.
|
||||
|
||||
* Compute nodes
|
||||
The number and hardware configuration of the compute nodes depend on the
|
||||
following:
|
||||
|
||||
* Number of virtual machines
|
||||
* Applications that you plan to run on these virtual machines
|
||||
* Types of workloads
|
||||
|
||||
* Storage nodes
|
||||
The number and capacity of the storage nodes highly depend on the type of
|
||||
the storage, redundancy, and workloads that you run on the compute
|
||||
nodes. Therefore, the storage configuration for every deployment will
|
||||
vary significantly.
|
||||
|
||||
.. seealso::
|
||||
|
||||
- `OpenStack Architecture Design Guide
|
||||
<http://docs.openstack.org/arch-design/content/technical-considerations-general-purpose.html>`__
|
||||
- `OpenStack Operations Guide
|
||||
<http://docs.openstack.org/openstack-ops/content/>`_
|
||||
- :ref:`sysreqs_sample_target_node_config`
|
||||
|
|
@ -0,0 +1,16 @@
|
|||
.. _sysreq_hw_intro:
|
||||
|
||||
Hardware requirements
|
||||
---------------------
|
||||
|
||||
Planning hardware requirements for an OpenStack environment is a complex task
|
||||
that requires analysis of the applications that you plan to run in your cloud,
|
||||
as well as understanding how your cloud will expand over time. Therefore, the
|
||||
hardware requirements for Fuel Slave nodes will differ for each use case.
|
||||
However, hardware requirements for Fuel Master node are identical for all
|
||||
deployments.
|
||||
|
||||
.. seealso::
|
||||
|
||||
- :ref:`sysreq_master_node_hardware_recs`
|
||||
- :ref:`sysreq_fuel_slave_node_hw_recs`
|
||||
|
|
@ -0,0 +1,63 @@
|
|||
.. _sysreq_ironic_limitations:
|
||||
|
||||
Bare Metal service limitations
|
||||
------------------------------
|
||||
|
||||
When you deploy your environment using Fuel with Ironic, the OpenStack
|
||||
environment has the following limitations:
|
||||
|
||||
.. list-table:: **Limitation for an OpenStack environment with Ironic**
|
||||
:widths: 10 25
|
||||
:header-rows: 1
|
||||
|
||||
* - Category
|
||||
- Description
|
||||
* - Network
|
||||
- * Neutron with VLAN segmentation is the only supported networking
|
||||
option.
|
||||
* - Storage
|
||||
- * Ironic does not support attaching or booting from the volumes stored
|
||||
in Cinder.
|
||||
|
||||
* Ironic requires a swift-compatible object storage. You can use
|
||||
Swift or RADOS Gateway.
|
||||
|
||||
* - Security
|
||||
- * No tenant-level network separation is supported for physical machines
|
||||
on which you deploy instances. All physical machines are visible to
|
||||
all tenants and to each other on the physical network level.
|
||||
|
||||
* Neutron security groups do not apply to instances deployed on
|
||||
physical machines.
|
||||
|
||||
* - Virtualization platform
|
||||
- VMware vCenter as a hypervisor is not supported.
|
||||
* - Fuel plug-ins
|
||||
- Ironic supports all Fuel plug-ins as long as their requirements do not
|
||||
interfere with ironic limitations. For example, if a plug-in requires
|
||||
you to configure any other networking option but Neutron with VLAN
|
||||
segmentation, you cannot use this plug-in with ironic.
|
||||
* - Management
|
||||
- * Auto-discovery is not supported.
|
||||
|
||||
Ironic cannot automatically discover the physical machines that you
|
||||
will use to create instances. Therefore, you must have description of
|
||||
the server hardware available including CPU, RAM, disks, MAC
|
||||
addresses, and so on to manually discover them. You must also have
|
||||
information required to configure power and BIOS settings, such as
|
||||
IPMI address or FQDN, as well as the IPMI user name and password with
|
||||
administrator privileges for IPMI.
|
||||
|
||||
* Horizon is partially supported.
|
||||
|
||||
Although you can launch an instance on a physical machine using
|
||||
Horizon, you must perform all other operations with physical nodes
|
||||
through APIs or CLI.
|
||||
Many operations that are typically supported for virtual
|
||||
machines, such as pausing and resuming, are not supported for
|
||||
physical machines. However, they are still present in the Horizon UI.
|
||||
|
||||
* Only ``admin`` can manage operations with Ironic.
|
||||
|
||||
Only an OpenStack user with the ``admin`` role can operate the
|
||||
Ironic service.
|
||||
|
|
@ -0,0 +1,58 @@
|
|||
.. _sysreq_ironic_prereq:
|
||||
|
||||
Prerequisites for the OpenStack bare-metal service
|
||||
--------------------------------------------------
|
||||
|
||||
Before you deploy an OpenStack environment, you must verify that your
|
||||
environment meets the following network, hardware, and software prerequisites
|
||||
required to succesfully deploy and use the OpenStack Bare Metal service.
|
||||
|
||||
**Network prerequisites:**
|
||||
|
||||
* Configure a flat network that you will use for the nodes on which you run
|
||||
``ironic``. This network will appear as *baremetal* in the Fuel web UI.
|
||||
|
||||
* Prepare the nodes on which you plan to deploy ``ironic`` by configuring the
|
||||
following:
|
||||
|
||||
* A separate network interface for the *baremetal* network.
|
||||
|
||||
You must assign a separate network interface or a VLAN for the
|
||||
*baremetal* network on the controller node. If you need to configure
|
||||
this network interface only on some nodes, such as nodes with ``ironic``
|
||||
and ``controller`` roles, use network templates.
|
||||
|
||||
* Access to the IPMI network
|
||||
|
||||
Since Ironic provides out-of-band management through Intelligent
|
||||
Platform Management Interface (IPMI), the nodes on which you deploy
|
||||
Ironic must have access to the IPMI network with bare-metal servers that
|
||||
you will use for provisioning.
|
||||
|
||||
* Verify that the network interfaces of the physical servers that connect to
|
||||
the IPMI network have either static IP addresses or, if you use DHCP, the
|
||||
DNS service is enabled in the IPMI network and the physical servers have
|
||||
stable FQDN host names.
|
||||
|
||||
**Hardware prerequisites:**
|
||||
|
||||
Follow the general guidelines for hardware prerequisites described in the
|
||||
*System Prerequisites* section in the *Fuel Installation Guide*.
|
||||
|
||||
Fuel includes special drivers for Ironic and the default bootstrap images
|
||||
that Fuel uploads to Glance when you create an OpenStack environment. If you
|
||||
plan to use these default configurations, the bootstrap images are based on
|
||||
the image Fuel uses to provision the OpenStack nodes. However, if you plan to
|
||||
use different drivers and bootstrap images, you must verify that the bootstrap
|
||||
image contains drivers that support your hardware.
|
||||
|
||||
**Software prerequisites:**
|
||||
|
||||
Each Ironic driver has requirements for the images that you will use to
|
||||
provision instances on physical machines. If you use default Fuel drivers, see
|
||||
*Image requirements* in the Fuel User Guide.
|
||||
|
||||
.. seealso::
|
||||
|
||||
- :ref:`sysreq_ironic_limitations`
|
||||
- *Using networking templates* in *Fuel User Guide*
|
||||
|
|
@ -0,0 +1,116 @@
|
|||
.. _sysreqs_network_reqs:
|
||||
|
||||
Network requirements
|
||||
--------------------
|
||||
|
||||
Your OpenStack environment must have an efficient, scalable, and manageable
|
||||
network infrastructure that addresses your immediate business needs and
|
||||
future growth. All nodes must communicate with each other through
|
||||
allocated networks. Network configuration of your Fuel Slave nodes depends
|
||||
significantly on the network topology that you select.
|
||||
|
||||
Fuel deploys standard network topologies supported by Neutron, as well as
|
||||
extended Neutron's networking functionality using such plugins as ML2 and so
|
||||
on. Neutron is a flexible network manager that enables you to create
|
||||
complex network configurations. Neutron provides both level 2 and 3
|
||||
network virtualization, as well as IP address management (IPAM). In addition,
|
||||
Neutron has multiple open-source and enterprise-class plugins that enable
|
||||
interoperability with such networking technologies as virtual switches and
|
||||
software defined networking (SDN).
|
||||
|
||||
.. note::
|
||||
Since the introduction of Neutron, nova-network development efforts
|
||||
have been gradually reduced and may be deprecated in the future
|
||||
OpenStack releases. Neutron is recommended in all new deployments.
|
||||
|
||||
Fuel can deploy the following Neutron network topologies:
|
||||
|
||||
Neutron with VLAN segmentation
|
||||
Similar to nova-network VLAN Manager, in Neutron's VLAN segmentation
|
||||
topology a VLAN is assigned to each tenant. IP subnets and ranges in
|
||||
different tenants can overlap. This is the default networking option
|
||||
in Fuel. The disadvantage of this option is that you must configure your
|
||||
networking equipment, as well as provide the total number of tenants,
|
||||
before configuring the network.
|
||||
|
||||
If you select Neutron with VLAN segmentation, you must have at least 3
|
||||
network interfaces (NICs).
|
||||
|
||||
**Neutron with VLAN segmentation examples:**
|
||||
|
||||
+----------+------------------------+-------------------------+
|
||||
| | 3 NICs | 4 NICs |
|
||||
+----------+------------------------+-------------------------+
|
||||
| eth0 | Untagged port for | Port for Administrative |
|
||||
| | Administrative network | network |
|
||||
+----------+------------------------+-------------------------+
|
||||
| eth1 | Port for the following | Port for the following |
|
||||
| (br-eth1)| networks: | networks: |
|
||||
| | | |
|
||||
| | * Public/Floating | * Public/Floating |
|
||||
| | * Management | * Management |
|
||||
| | * Storage | |
|
||||
+----------+------------------------+-------------------------+
|
||||
| eth2 | Port for Private | Port for Private network|
|
||||
| (br-eth2)| network. The number of | with defined VLAN ID |
|
||||
| | VLANs depends on the | range |
|
||||
| | number of tenant | |
|
||||
| | networks with a | |
|
||||
| | continuous range. | |
|
||||
+----------+------------------------+-------------------------+
|
||||
| eth3 | N/A | Port for Storage |
|
||||
| (br-eth3)| | network |
|
||||
+----------+------------------------+-------------------------+
|
||||
|
||||
Neutron with tunneling segmentation
|
||||
You can choose between VXLAN and GRE segmentation, with VXLAN being a
|
||||
default and preferred option. In both VXLAN and GRE segmentations,
|
||||
tenant traffic is isolated by encapsulation the traffic in tunnels.
|
||||
Both VXLAN and GRE segmentation is more flexible in terms of the number
|
||||
of tenants (supports up to 65534 tenants). Network hardware configuration
|
||||
is significantly simpler compared to the VLAN segmentation and does not
|
||||
need to be synchronized with your L2 switch configuration. Both VXLAN
|
||||
and GRE support subnet overlapping in different tenants. However, the
|
||||
disadvantage of using GRE segmentation is that GRE encapsulation
|
||||
decreases the network speed between the instances, as well as increases
|
||||
the CPU usage on the compute and controller nodes.
|
||||
|
||||
.. note::
|
||||
To use VXLAN segmentation, your network hardware must support VXLAN
|
||||
segmentation.
|
||||
|
||||
You can configure GRE segmentation using CLI. For more information, see:
|
||||
*Fuel CLI Reference*.
|
||||
|
||||
**Neutron with GRE segmentation examples:**
|
||||
|
||||
+----------+-------------------+-------------------+---------------------+
|
||||
| | 2 NICs | 3 NICs | 4 NICs |
|
||||
+----------+-------------------+-------------------+---------------------+
|
||||
| eth0 | Untagged port for | Untagged port for | Untagged port for |
|
||||
| | Administrative | Administrative | Administrative |
|
||||
| | network | network | network |
|
||||
+----------+-------------------+-------------------+---------------------+
|
||||
| eth1 | Port for the | Port for the | Port for Management |
|
||||
| (br-eth1)| following | following | network |
|
||||
| | networks: | networks: | |
|
||||
| | | | |
|
||||
| | * Public/Floating | * Public/Floating | |
|
||||
| | * Management | * Management | |
|
||||
| | * Storage | | |
|
||||
+----------+-------------------+-------------------+---------------------+
|
||||
| eth2 | N/A | Port for Storage | Port for Public/ |
|
||||
| (br-eth2)| | network | Floating network |
|
||||
+----------+-------------------+-------------------+---------------------+
|
||||
| eth3 | N/A | N/A | Port for Storage |
|
||||
| (br-eth3)| | | network |
|
||||
+----------+-------------------+-------------------+---------------------+
|
||||
|
||||
Routing recommendations for Neutron networking topologies:
|
||||
|
||||
* Public network: use the default routing through the router.
|
||||
* Management network: use management network to access your management
|
||||
infrastructure (L3 connectivity, if necessary).
|
||||
* Administrative network or only the Fuel Master node: must have the Internet
|
||||
access through a dedicated NIC.
|
||||
* Storage and Private networks (VLANs): isolate from other networks.
|
||||
|
|
@ -0,0 +1,40 @@
|
|||
.. _sysreqs_sample_target_node_config:
|
||||
|
||||
Sample hardware configuration for Fuel Slave nodes
|
||||
--------------------------------------------------
|
||||
|
||||
The example provided in this section is a general-purpose medium-size
|
||||
hardware configuration that you can use for a variety of OpenStack
|
||||
installations and later moderately scale to accommodate
|
||||
growing requirements of your environment.
|
||||
|
||||
.. note::
|
||||
This example is not a best practice document of how to design an
|
||||
OpenStack environment. The purpose of the example is to help
|
||||
OpenStack administrators to understand how to plan an installation
|
||||
and demonstrate how an OpenStack environment may look.
|
||||
|
||||
The sample OpenStack environment includes:
|
||||
|
||||
+--------------------------+-----------------------------+
|
||||
| Number of servers | 12 |
|
||||
| | The servers include: |
|
||||
| | |
|
||||
| | * 1 Fuel Master node |
|
||||
| | * 3 Controller nodes |
|
||||
| | * 3 Storage nodes |
|
||||
| | * 5 Compute nodes |
|
||||
+--------------------------+-----------------------------+
|
||||
| Network | Neutron, using VLAN or GRE |
|
||||
| | topology |
|
||||
+--------------------------+-----------------------------+
|
||||
| Storage | Ceph as back end for Cinder |
|
||||
| | Glance and Nova (ephemeral |
|
||||
| | storage) |
|
||||
+--------------------------+-----------------------------+
|
||||
| Additional Components | No additional components. |
|
||||
| | If you want to install |
|
||||
| | Ceilometer with the MongoDB |
|
||||
| | database, you must add three|
|
||||
| | more servers. |
|
||||
+--------------------------+-----------------------------+
|
||||
|
|
@ -0,0 +1,24 @@
|
|||
.. _sysreqs_sample_target_node_config_compute:
|
||||
|
||||
Compute nodes
|
||||
-------------
|
||||
|
||||
Your virtual machines are hosted on the compute nodes; therefore,
|
||||
you must allocate enough resources to run these virtual machines.
|
||||
|
||||
Each compute node must include:
|
||||
|
||||
+---------------+----------------------------------+
|
||||
| CPU | Dual-socket CPU with a minimum |
|
||||
| | of 4 cores per socket |
|
||||
+---------------+----------------------------------+
|
||||
| RAM | 64 GB |
|
||||
+---------------+----------------------------------+
|
||||
| Storage | Hardware RAID 1 controller with |
|
||||
| | at least 500 GB capacity for |
|
||||
| | the host operating system disk |
|
||||
+---------------+----------------------------------+
|
||||
| Network | * For testing: 2 x 1 Gbit/s NICs |
|
||||
| | * For production: 2 x 10 Gbit/s |
|
||||
| | NICs |
|
||||
+---------------+----------------------------------+
|
||||
|
|
@ -0,0 +1,34 @@
|
|||
.. _sysreqs_sample_target_node_config_controller:
|
||||
|
||||
Controller nodes
|
||||
----------------
|
||||
|
||||
In this example, we use Ceph as a back end for ephemeral storage.
|
||||
Therefore, in addition to the basic OpenStack components and a MySQL database,
|
||||
controller nodes require sufficient resources to run Ceph monitors.
|
||||
|
||||
Each controller node must include:
|
||||
|
||||
+--------------+-----------------------------------+
|
||||
| CPU | 2 CPUs with at least six physical |
|
||||
| | cores each |
|
||||
+--------------+-----------------------------------+
|
||||
| RAM | * For testing: 2 GB |
|
||||
| | * For production: |
|
||||
| | |
|
||||
| | * 24 GB (minimum) |
|
||||
| | * 64 GB for deployments of |
|
||||
| | 1000 VMs or more |
|
||||
+--------------+-----------------------------------+
|
||||
| Network | * For testing: 2 x 1 Gbit/s NICs |
|
||||
| | * For production: 2 x 10 Gbit/s |
|
||||
| | NICs |
|
||||
+--------------+-----------------------------------+
|
||||
| Storage | Hardware RAID 1 with at least 1 TB|
|
||||
| | formatted capacity for the host |
|
||||
| | host operating system disk |
|
||||
| | |
|
||||
| | Larger disks may be warranted |
|
||||
| | depending on the expected database|
|
||||
| | and log storage requirements. |
|
||||
+--------------+-----------------------------------+
|
||||
|
|
@ -0,0 +1,38 @@
|
|||
.. _sysreqs_sample_target_node_config_storage:
|
||||
|
||||
Storage nodes
|
||||
-------------
|
||||
|
||||
We recommend that you separate Ceph nodes for scalability and robustness.
|
||||
The hardware estimate provided below is based on the requirement of 0.5 cores
|
||||
per Ceph-OSD CPU and 1 GB of RAM per 1 TB of Ceph-OSD space. You can configure
|
||||
all Ceph storage and journal hard disks in JBOD (Just a Bunch of Disks) mode
|
||||
on the RAID controller or plug them directly to the available SATA or SAS ports
|
||||
on the mainboard.
|
||||
|
||||
Each storage node must include:
|
||||
|
||||
+------------------------+---------------------------------+
|
||||
| CPU | Single-socket CPU with at least |
|
||||
| | 4 physical cores |
|
||||
+------------------------+---------------------------------+
|
||||
| RAM | 24 GB |
|
||||
+------------------------+---------------------------------+
|
||||
| Storage | RAID 1 controller with at least |
|
||||
| | 500 GB capacity for the host |
|
||||
| | operating system disk |
|
||||
| | |
|
||||
| | For production installations, |
|
||||
| | set the Ceph object replication |
|
||||
| | factor to 3 or greater. |
|
||||
+------------------------+---------------------------------+
|
||||
| Network | * For testing: 2 x 1 Gbit/s NICs|
|
||||
| | * For production: 2 x 10 Gbit/s |
|
||||
| | NICs |
|
||||
+------------------------+---------------------------------+
|
||||
| Storage | * 18 TB for Ceph storage |
|
||||
| | (6 x 3 TB) |
|
||||
| | * 1-2 x 64 GB SSDs or more, for |
|
||||
| | the Ceph journal |
|
||||
+------------------------+---------------------------------+
|
||||
|
||||
|
|
@ -0,0 +1,37 @@
|
|||
.. _sysreq_storge_reqs:
|
||||
|
||||
Storage requirements
|
||||
--------------------
|
||||
|
||||
When planning storage for your OpenStack environment, understand the
|
||||
difference between the two types of storage that OpenStack uses:
|
||||
persistent and ephemeral.
|
||||
|
||||
The nova-compute service manages ephemeral storage that is used as temporary
|
||||
storage for the operating system of virtual machine instances. When you
|
||||
delete an instance, nova-compute deletes the ephemeral storage as well.
|
||||
If you do not select any additional storage options, the virtual machine
|
||||
volumes will be stored on the local disks of the compute nodes, in the
|
||||
virtual storage partition. However, if you enable Ceph RBD back end for
|
||||
ephemeral volumes, nova-compute stores virtual machine volumes in Ceph.
|
||||
|
||||
Persistent storage is the storage that exists outside an instance, in contrast
|
||||
to ephemeral storage.
|
||||
|
||||
Fuel deploys storage for the following types of persistent data:
|
||||
|
||||
* Glance, for image data, which can use either Swift or Ceph RBD as a
|
||||
storage back end.
|
||||
* Cinder, for block data, which can use either LVM or Ceph RBD as a
|
||||
storage back end.
|
||||
* Ceph RadosGW, for object storage, with Ceph RBD as storage back end.
|
||||
|
||||
.. note::
|
||||
Fuel plugins may provide additional storage options. For more information,
|
||||
see the
|
||||
`OpenStack Driverlog for the Fuel project <http://stackalytics.com/report/driverlog?project_id=openstack%2Ffuel>`_.
|
||||
|
||||
.. seealso::
|
||||
|
||||
- `Storage Decisions
|
||||
<http://docs.openstack.org/openstack-ops/content/storage_decision.html>`_
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
.. _sysreq_intro:
|
||||
|
||||
System requirements
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This section describes how to configure hardware nodes to
|
||||
accommodate your OpenStack workloads. Since there are many possible use cases
|
||||
for an OpenStack environment, the number and configurations of your servers
|
||||
will also vary. While this section provides clear hardware requirements for the
|
||||
Fuel Master node, it can only provide guidelines on how to configure the Fuel
|
||||
Slave nodes. For reference, a sample hardware configuration of
|
||||
a medium-sized OpenStack environment is described at the end of this section.
|
||||
|
||||
This section includes the following topics:
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 3
|
||||
|
||||
sysreq/sysreq_hw_intro
|
||||
sysreq/sysreq_fuel_master_node_hw_requirements
|
||||
sysreq/sysreq_fuel_slave_node_hw_recs
|
||||
sysreq/sysreq_network_requirements
|
||||
sysreq/sysreq_fuel_master_node_network_reqs
|
||||
sysreq/sysreq_storage_reqs
|
||||
sysreq/sysreq_additional_components
|
||||
sysreq/sysreq_ironic_prereq
|
||||
sysreq/sysreq_ironic_limitations
|
||||
sysreq/sysreq_sample_configuration
|
||||
sysreq/sysreq_sample_configuration_controllers
|
||||
sysreq/sysreq_sample_configuration_compute
|
||||
sysreq/sysreq_sample_configuration_storage
|
||||
|
|
@ -0,0 +1,181 @@
|
|||
.. _upgrade_apply_patches:
|
||||
|
||||
Apply patches
|
||||
-------------
|
||||
|
||||
You can apply only the patches you need one by one or you can
|
||||
apply all accumulated patches in one go.
|
||||
|
||||
The documentation for each patch is available in the corresponding
|
||||
release notes.
|
||||
|
||||
.. note:: Maintenance Updates are only available online. Currently
|
||||
there is no option to run these updates from a local
|
||||
repository.
|
||||
|
||||
Check each patch item and proceed with the instructions.
|
||||
|
||||
**To patch the Fuel Master node:**
|
||||
|
||||
#. Log in to the Fuel Master node.
|
||||
|
||||
* If you use a local repository, update it by typing::
|
||||
|
||||
fuel-createmirror -M
|
||||
|
||||
#. Run the command specified in the documentation to download and install the patch.
|
||||
|
||||
**To patch a Fuel Slave node:**
|
||||
|
||||
#. Run the command specified in the documentation to download and
|
||||
install the patch.
|
||||
|
||||
**Apply all accumulated changes in one go:**
|
||||
|
||||
Before starting the update, back up all sensitive data that
|
||||
can be changed during the the whole lifetime of your environment
|
||||
and the Fuel Master node. We recommend to apply the updates to one
|
||||
node at a time, so that you can interrupt the update procedure whenever
|
||||
an issue occurs.
|
||||
|
||||
If you have configured any custom repositories, Fuel will use fetch
|
||||
the upgrade packages from these repositories.
|
||||
|
||||
.. note::
|
||||
This set of actions should be applied carefully and with
|
||||
consideration. It is strongly recommended that you do this on your
|
||||
test staging environment before applying the updates to production.
|
||||
|
||||
Patch the Fuel Master node
|
||||
--------------------------
|
||||
|
||||
#. Back up your data with dockerctl backup. This will save the data
|
||||
to ``/var/backup/fuel/``.
|
||||
#. Run ``yum update``.
|
||||
#. Run ``dockerctl destroy all``.
|
||||
#. Run ``dockerctl start all``.
|
||||
#. Wait for the new containers deployment to finish.
|
||||
|
||||
Patch an Ubuntu slave node
|
||||
--------------------------
|
||||
|
||||
#. Run ``apt-get update``.
|
||||
#. Run ``apt-get upgrade``.
|
||||
#. Apply all the additional configuration options as described in the
|
||||
supporting documentation.
|
||||
#. Reboot the node.
|
||||
|
||||
Apply Puppet changes on a slave node
|
||||
------------------------------------
|
||||
|
||||
You may want to apply all changes on a slave node or run a single
|
||||
granular task so that Fuel Puppet changes take effect.
|
||||
|
||||
**To run a complete Puppet cycle on a Fuel Slave node:**
|
||||
|
||||
#. Update fuel-libraryX.X on Fuel Master ``yum update``
|
||||
#. Run ``fuel node --node NODE_ID --deploy``
|
||||
|
||||
**To update Puppet manifests and apply a single task:**
|
||||
|
||||
#. Update fuel-libraryX.X on Fuel Master ``yum update``
|
||||
#. Run ``fuel node --node node-XX --task rsync_core_puppet hiera globals TASK``
|
||||
|
||||
.. note::
|
||||
The tasks rsync_core_puppet, hiera, and globals are required for
|
||||
processing any Puppet changes.
|
||||
|
||||
**Verify a patch:**
|
||||
|
||||
Verify a patch on the Fuel Master node
|
||||
--------------------------------------
|
||||
|
||||
To verify the packages on the Fuel Master node:
|
||||
|
||||
#. Log in to the Fuel Master node CLI.
|
||||
#. Type:
|
||||
|
||||
::
|
||||
|
||||
yum clean expire-cache
|
||||
yum -y update
|
||||
|
||||
Verify a patch on a Fuel slave node
|
||||
-----------------------------------
|
||||
|
||||
To verify the packages are up-to-date on the Fuel Slave nodes:
|
||||
|
||||
#. Log in to the Fuel Master node CLI.
|
||||
#. Update the list of available packages::
|
||||
|
||||
apt-get update
|
||||
|
||||
#. Update all packages::
|
||||
|
||||
apt-get dist-upgrade
|
||||
|
||||
#. Log in to the Fuel Master node GUI:
|
||||
#. Click :guilabel:`Support`.
|
||||
#. Generate and download a diagnostic snapshot by clicking
|
||||
:guilabel:`Generate Diagnostic Snapshot`.
|
||||
|
||||
The Fuel Master node generates ``ubuntu_installed_debs.txt``.
|
||||
|
||||
#. Analyze ``ubuntu_installed_debs.txt`` to verify the versions of the packages.
|
||||
|
||||
Additionally, you can analyze the ``ubuntu_repo_list.txt`` file to verify
|
||||
the repositories.
|
||||
|
||||
**Roll back a patch:**
|
||||
|
||||
.. note::
|
||||
The rollback instructions listed here are for advanced administrators.
|
||||
If you are not sure how to plan and execute the rollbacks,
|
||||
your best option is to contact `Mirantis support <https://www.mirantis.com/services/enterprise-support-services/>`__.
|
||||
|
||||
Roll back the Fuel Master node
|
||||
------------------------------
|
||||
|
||||
#. Roll back the packages on the Fuel Master node.
|
||||
`Refer to this article <https://access.redhat.com/solutions/64069>`__ as an example.
|
||||
#. Roll back all the changes to the configuration you made when applying
|
||||
the patching instructions.
|
||||
#. Run ``dockerctl destroy all``.
|
||||
#. Run ``dockerctl start all``.
|
||||
#. Wait for bootstrap to complete.
|
||||
|
||||
Roll back an Ubuntu slave node
|
||||
------------------------------
|
||||
|
||||
You must identify the packages to roll back and where to get
|
||||
their specific versions, install the packages and roll back the
|
||||
changes to the configuration.
|
||||
|
||||
**To roll back an Ubuntu slave node:**
|
||||
|
||||
#. Evacuate all the running resources from the node.
|
||||
#. Make sure no new workloads are scheduled to the node: Put nova
|
||||
services in maintenance, turn on Pacemaker maintenance mode.
|
||||
#. Look up the packages you want to roll back in ``/var/log/apt/history.log``
|
||||
and ``/var/log/dpkg.log``.
|
||||
#. Figure out where to get the old package version. Run ``apt-cache policy``.
|
||||
#. Figure out if the old package version is available locally.
|
||||
#. If it is, install these versions using dpkg. Otherwise, check the
|
||||
snapshots of previous repositories on
|
||||
`http://mirror.fuel-infra.org/mos/snapshots` and pick the
|
||||
repository that contains the packages you need.
|
||||
#. Add this repository to the environment configuration.
|
||||
#. On the Fuel Master node run::
|
||||
|
||||
fuel node --node-id <comma_separated_list_of_nodes_you_want_to_update_repo> \
|
||||
--tasks upload_core_repos
|
||||
|
||||
This will propagate the new repos configuration.
|
||||
|
||||
#. Install the packages with specific versions::
|
||||
|
||||
apt-get install <pkg1>=<ver1> <pkg2>=<ver2>
|
||||
|
||||
#. Roll back all the changes to the configuration you made when applying
|
||||
the patching instructions.
|
||||
#. Reboot the node.
|
||||
|
|
@ -0,0 +1,122 @@
|
|||
|
||||
.. _upgrade-patch-top-ug:
|
||||
|
||||
Upgrade the Fuel Master node
|
||||
----------------------------
|
||||
|
||||
If you have a functional Fuel installation, you can
|
||||
upgrade the Fuel software to the latest version
|
||||
without reinstalling your environments.
|
||||
|
||||
.. note::
|
||||
Upgrades are not supported for Fuel 4.x or earlier. If you use Fuel 4.x
|
||||
or earlier, you must install new instance of Fuel and deploy your
|
||||
environments from scratch.
|
||||
|
||||
After you upgrade Fuel, you can only deploy new environments of the
|
||||
corresponding Fuel version. Environments deployed using older versions
|
||||
of Fuel will remain operational.
|
||||
|
||||
**To upgrade the Fuel Master node:**
|
||||
|
||||
#. Verify that no installations are in progress in any of your OpenStack
|
||||
environments.
|
||||
|
||||
#. Download and install the ``fuel-octane`` package using the ``yum install``
|
||||
command:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ yum install fuel-octane
|
||||
|
||||
#. Back up the configuration of
|
||||
the Fuel Master node to an archive:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
octane fuel-backup --to <path-to-archive> --admin-password <admin-password>
|
||||
|
||||
**Example:**
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ octane fuel-backup --to /tmp/fuel-backup.7.0.tar.gz --admin-password admin
|
||||
|
||||
#. Back up package repositories and other binary artifacts from the Fuel
|
||||
Master node:
|
||||
|
||||
**Example:**
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ octane fuel-repo-backup --to /tmp/fuel-repo-backup.7.0.tar.gz
|
||||
|
||||
#. Copy the backup files to a secure external location, such as
|
||||
a removable USB drive or network server. If you copy the files to
|
||||
a network server, use SSH.
|
||||
|
||||
.. note::
|
||||
|
||||
When you reinstall the Fuel Master node, all configuration files are
|
||||
deleted. Therefore, if you fail to back up the Fuel Master node and
|
||||
repository configuration files, you will not be able to manage the
|
||||
OpenStack environments created by the old version of Fuel.
|
||||
|
||||
#. Power off the Fuel Master node.
|
||||
|
||||
#. Install the latest version of the Fuel Master node as described in
|
||||
:ref:`install_intro`.
|
||||
|
||||
.. note::
|
||||
|
||||
The new Fuel Master node must have the same IP address as the original
|
||||
Fuel Master node. Otherwise, you cannot restore the configuration from
|
||||
the backup.
|
||||
|
||||
|
||||
#. Copy the backup files to the location on the new Fuel Master node.
|
||||
|
||||
For example, in the ``/tmp`` directory.
|
||||
|
||||
#. Log in to the new Fuel Master node.
|
||||
|
||||
#. Install the ``fuel-octane`` package:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ yum install fuel-octane
|
||||
|
||||
#. Restore the configuration of the original Fuel Master node and the OpenStack
|
||||
environments:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ octane fuel-restore --from /tmp/fuel-backup.7.0.tar.gz
|
||||
|
||||
#. Restore repositories and binary artifacts from the old version:
|
||||
|
||||
**Example:**
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ octane fuel-repo-restore --from /tmp/fuel-repo-backup.7.0.tar.gz
|
||||
|
||||
.. warning::
|
||||
|
||||
The Fuel Master node must have at least 2 GB of RAM
|
||||
to decompress the ``gzip`` upgrade archive.
|
||||
|
||||
When Fuel completes the upgrade, the *New Release available* message appears
|
||||
in the :guilabel:`Releases` tab.
|
||||
|
||||
#. If you want to use CentOS-based bootstrap, rebuild the bootstrap image:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ octane update-bootstrap-centos
|
||||
|
||||
#. Reboot all nodes that are in the ``Discover`` status.
|
||||
|
||||
.. seealso::
|
||||
|
||||
- :ref:`Configure a bootstrap image <install_configure_bootstrap>`.
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
|
||||
.. _upgrade-internals:
|
||||
|
||||
Overview of the Fuel upgrade process
|
||||
------------------------------------
|
||||
|
||||
The upgrade is implemented with three upgrade engines, which are python
|
||||
modules:
|
||||
|
||||
* **Host system engine:**
|
||||
|
||||
#. Copies new repositories to Fuel Master node.
|
||||
#. Installs a package and all the required dependencies such as
|
||||
Puppet manifests, bootstrap images, provisioning images etc.
|
||||
|
||||
* **Docker engine:**
|
||||
|
||||
#. Points the supervisor to a new directory with the configuration
|
||||
files. No containers are started by the supervisor at this time.
|
||||
#. Stops old containers.
|
||||
#. Uploads new Docker images.
|
||||
#. Runs containers one by one.
|
||||
#. Generates new supervisor configuration files.
|
||||
#. Verifies the services running in the containers.
|
||||
|
||||
* **OpenStack engine:**
|
||||
|
||||
#. Installs all data required for OpenStack patching.
|
||||
#. Adds new releases using the Nailgun REST API.
|
||||
This allows the full list of OpenStack releases to be displayed
|
||||
in the Fuel web UI.
|
||||
|
|
@ -0,0 +1,77 @@
|
|||
.. _upgrade_local_repo:
|
||||
|
||||
Set up a local repository
|
||||
-------------------------
|
||||
|
||||
Fuel downloads the OpenStack and operating system packages
|
||||
from the predefined repositories on the Fuel Master node.
|
||||
If your Fuel Master node does not have an Internet connection,
|
||||
you must configure a local repository mirror with the required
|
||||
packages and configure Fuel to use this repository.
|
||||
|
||||
You can set up a local repository in the Fuel web UI
|
||||
or through Fuel CLI using the ``fuel-createmirror`` script.
|
||||
|
||||
**To set up a local repository in the Fuel web UI**
|
||||
|
||||
#. In the Fuel web UI, navigate to the :guilabel:`Settings` tab
|
||||
and then scroll down to the :guilabel:`Repositories` section.
|
||||
#. Change the path under :guilabel:`URI`.
|
||||
|
||||
**To set up a local repository with the ``fuel-createmirror`` script**
|
||||
|
||||
#. Log in to the Fuel Master node CLI.
|
||||
#. Run the ``fuel-createmirror`` script:
|
||||
|
||||
* If you use the default Fuel root password, type:
|
||||
|
||||
::
|
||||
|
||||
fuel-createmirror
|
||||
|
||||
* If you change the default Fuel root password, type:
|
||||
|
||||
::
|
||||
|
||||
fuel-createmirror --password PASSWORD
|
||||
|
||||
#. Restart the the docker daemon
|
||||
|
||||
::
|
||||
|
||||
service docker restart
|
||||
|
||||
Alternatively (recommended), reboot the Fuel Master node.
|
||||
|
||||
About the fuel-createmirror script
|
||||
----------------------------------
|
||||
|
||||
The ``fuel-createmirror`` is a built-in Fuel script that enables
|
||||
you to modify the Fuel repository sources from the CLI.
|
||||
|
||||
* The script supports only RSYNC mirrors.
|
||||
See the `the list of official upstream Ubuntu mirrors <https://launchpad.net/ubuntu/+archivemirrors>`_.
|
||||
|
||||
* The script uses a Docker container with Ubuntu to support dependencies
|
||||
resolution.
|
||||
|
||||
* To view help information, type ``fuel-createmirror -h``.
|
||||
|
||||
* The script supports running behind an HTTP proxy configured to
|
||||
Port 873 (rsync). The following environment variables can be set either
|
||||
system-wide (via ~/.bashrc), or in the script configuration file:
|
||||
|
||||
::
|
||||
|
||||
http_proxy=http://username:password@host:port/
|
||||
RSYNC_PROXY=username:password@host:port
|
||||
|
||||
* You can also configure Docker to use the proxy to download the Ubuntu
|
||||
image needed to resolve the packages dependencies. Add the environment
|
||||
variables to the `/etc/sysconfig/docker` file, and export them:
|
||||
|
||||
::
|
||||
|
||||
http_proxy=http://username:password@host:port/
|
||||
RSYNC_PROXY=username:password@host:port
|
||||
export http_proxy RYSNC_PROXY
|
||||
|
|
@ -0,0 +1,89 @@
|
|||
.. raw:: pdf
|
||||
|
||||
PageBreak oneColumn
|
||||
|
||||
.. _upgrade_intro:
|
||||
|
||||
Upgrade Fuel
|
||||
~~~~~~~~~~~~
|
||||
|
||||
You can upgrade the Fuel Master node to the latest Fuel version.
|
||||
|
||||
The following table describes available upgrades for the Fuel software:
|
||||
|
||||
+----------------------+------------------------+--------------------------+
|
||||
| Initial Fuel version | Fuel is upgraded to | Upgraded Fuel can manage |
|
||||
+======================+========================+==========================+
|
||||
| 5.0 | 5.1, then to 5.1.1, | 2014.1-5.0 |
|
||||
| | then to 6.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, | 2014.1-5.0 |
|
||||
| | | |
|
||||
| | then to 5.1.1 | 2014.1.1-5.0.1 |
|
||||
| | | |
|
||||
| | then to 6.0 | 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 | 2014.1.1-5.0.1 |
|
||||
| | | |
|
||||
| | then to 6.0 | 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, then apply all 6.1| 2014.2.6.0 |
|
||||
| | updates, then to 7.0 | 2014.2.2-6.1 |
|
||||
| | | 2015.x-7.0 |
|
||||
| | | |
|
||||
| | | |
|
||||
| | | |
|
||||
+----------------------+------------------------+--------------------------+
|
||||
| 6.1 | Apply all 6.1 updates, | 2014.2-6.0 |
|
||||
| | | |
|
||||
| | then to 7.0 | 2014.2.2-6.1 |
|
||||
| | | |
|
||||
| | | 2015.x-7.0 |
|
||||
| | | |
|
||||
+----------------------+------------------------+--------------------------+
|
||||
| 7.0 | Apply all 7.0 updates, | 2014.2.2-6.1 |
|
||||
| | | |
|
||||
| | then to 8.0 | 2015.1.0-7.0 |
|
||||
| | | |
|
||||
| | | liberty-8.0 |
|
||||
+----------------------+------------------------+--------------------------+
|
||||
|
||||
This section includes the following topics.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 3
|
||||
|
||||
upgrade/upgrade-fuel
|
||||
upgrade/upgrade-internals
|
||||
upgrade/upgrade-local-repo
|
||||
upgrade/upgrade-apply-patches
|
||||
|
||||
.. note:: Fuel does not support upgrades for plugins. The old plugin
|
||||
versions may not be compatible with the new version of Fuel.
|
||||
Therefore, you must uninstall the Fuel plugins before
|
||||
upgrading Fuel. See :ref:`plugins_upgrade_uninstall_plugin`.
|
||||
|
|
@ -0,0 +1,15 @@
|
|||
.. _vsphere_boot_master:
|
||||
|
||||
Boot the Fuel Master node
|
||||
-------------------------
|
||||
|
||||
#. When the Mirantis ISO boot menu appears, press the **Tab** key
|
||||
on the keyboard and modify the last kernel parameter ``showmenu``
|
||||
to ``yes``. Press **Enter**.
|
||||
#. Wait for the Fuel Master node installation to complete.
|
||||
|
||||
To access the Fuel Web UI, your browser must have an access
|
||||
to the Fuel Master node through the IP gateway that is connected
|
||||
to the Port Group network that you configured in :ref:`vsphere_configure_network`.
|
||||
|
||||
Proceed to :ref:`vsphere_verify_master`.
|
||||
|
|
@ -0,0 +1,27 @@
|
|||
.. _configure_esxi:
|
||||
|
||||
Configure ESXi host networking
|
||||
------------------------------
|
||||
|
||||
To integrate Mirantis OpenStack with VMware vCenter,
|
||||
you must configure the VMware ESXi host networking.
|
||||
|
||||
**To configure ESXi host networking**:
|
||||
|
||||
#. In VMware vSphere web-client open the ESXi host page.
|
||||
#. Select **Manage** > **Networking**.
|
||||
#. Click **Add network**.
|
||||
The **Add networking** wizard starts.
|
||||
#. In the **Add Networking** wizard, select the Virtual Machine Port
|
||||
group.
|
||||
#. Select the **Virtual Machine Port Group** option
|
||||
to ensure that the network is created in vSwitch0.
|
||||
#. Create a network called **br100**.
|
||||
|
||||
.. note::
|
||||
You must name the network ``br100``. Otherwise, Fuel will not
|
||||
be able to communicate with VMware vSphere.
|
||||
|
||||
#. In the VLAN ID field, type a VLAN Tag.
|
||||
#. Proceed to :ref:`vsphere_upload_iso`.
|
||||
|
||||
|
|
@ -0,0 +1,39 @@
|
|||
.. _vsphere_configure_network:
|
||||
|
||||
Configure networks
|
||||
------------------
|
||||
|
||||
To enable inter-node communication, you must configure networks on
|
||||
VMware vCenter.
|
||||
|
||||
Configure a network for Fuel Admin (PXE) traffic
|
||||
------------------------------------------------
|
||||
|
||||
You must configure a network for the Fuel Admin (PXE) traffic
|
||||
and enable Promiscuous mode.
|
||||
|
||||
**To configure a network for the Fuel Admin (PXE) traffic:**
|
||||
|
||||
#. Go to the vCenter screen.
|
||||
#. Choose **Hosts**.
|
||||
#. Select the host on which you want to run the Fuel Master node.
|
||||
#. Click the **Networking** button.
|
||||
#. Click the **Add Host Networking** icon.
|
||||
|
||||
Create a vCenter Port Group network
|
||||
-----------------------------------
|
||||
|
||||
You must create a Port Group with Promiscuous mode.
|
||||
|
||||
**To create a vCenter Port Group network:**
|
||||
|
||||
#. Choose a Port Group connection type.
|
||||
#. Choose a switch.
|
||||
#. Name your network and set the VLAN number. This is optional
|
||||
and depends on your underlying network infrastructure.
|
||||
#. After the network is created, select the network on the network map;
|
||||
then click the **Edit Settings** icon.
|
||||
#. Click **Security**.
|
||||
#. Verify that the **Promiscuous mode** is set to **Accept**.
|
||||
#. Click "OK".
|
||||
#. Proceed to :ref:`vsphere_create_vm`.
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
.. _vsphere_create_vm:
|
||||
|
||||
Create the Fuel Master node virtual machine
|
||||
-------------------------------------------
|
||||
|
||||
You need to create a new virtual machine with a guest
|
||||
operating system to run the Fuel Master node on it.
|
||||
|
||||
**To create the Fuel Master node virtual machine:**
|
||||
|
||||
#. On the vCenter screen choose **Virtual Machines**.
|
||||
#. Click **Create a Virtual Machine**.
|
||||
#. Click **Create a new virtual machine**.
|
||||
Do not use templates.
|
||||
#. Name your new VM and choose the datacenter where the Mirantis ISO
|
||||
is located.
|
||||
#. Select a compute resource (ESXi host), storage, and compatibility
|
||||
for the VM.
|
||||
#. Select a guest operating system.
|
||||
#. Proceed to: :ref:`vsphere_mount_iso`.
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
.. _vsphere_install_master:
|
||||
|
||||
Install the Fuel Master node on VMware vSphere
|
||||
----------------------------------------------
|
||||
You need to install the Fuel Master node on the created
|
||||
virtual machine.
|
||||
|
||||
**To install the Fuel Master node on VMware vSphere:**
|
||||
|
||||
#. At the Virtual Machines screen, select the Fuel VM and run it
|
||||
by clicking the **Power on** icon.
|
||||
#. Click the **Open a virtual machine console** icon.
|
||||
#. When the BIOS appears, use the arrow keys on your keyboard
|
||||
to navigate to the **Boot** tab. Then move the highlighted selection
|
||||
to the **CD-ROM drive**.
|
||||
#. Using the **+** button on the keyboard, move the **CD-ROM Drive** item
|
||||
to the top level.
|
||||
#. Navigate to the **Exit** tab, choose **Exit Saving Changes**,
|
||||
and confirm your decision.
|
||||
#. Proceed to :ref:`vsphere_boot_master`.
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
.. _vsphere_mount_iso:
|
||||
|
||||
Mount the Fuel ISO
|
||||
------------------
|
||||
|
||||
You must mount the Fuel ISO to install the Fuel Master node
|
||||
on the virtual machine.
|
||||
|
||||
**To mount the Fuel ISO:**
|
||||
|
||||
#. For the CD/DVD drive, choose **Datastore ISO File** from
|
||||
the dropdown menu on the right.
|
||||
#. Navigate through the datastore and choose the ISO you uploaded earlier.
|
||||
#. Enable the CD/DVD drive by clicking the **Connect...** checkbox
|
||||
opposite the drive.
|
||||
#. Go to the **VM Options** tab and expand the **Boot Options** submenu.
|
||||
#. Enable the "Force BIOS setup" item.
|
||||
#. Click **Next**.
|
||||
#. Verify the new Virtual Machine settings and proceed.
|
||||
#. Proceed to :ref:`vsphere_install_master`.
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
.. _vmware_prereq:
|
||||
|
||||
VMware vSphere prerequisites
|
||||
----------------------------
|
||||
|
||||
Before you install Fuel and use your Mirantis OpenStack environment
|
||||
in intergration with vSphere, you must configure all components
|
||||
of VMware vSphere.
|
||||
|
||||
.. note::
|
||||
|
||||
The vCenter Server supported versions are 5.1, 5.5, and 6.0.
|
||||
|
||||
Complete the following steps:
|
||||
|
||||
* Install ESXi.
|
||||
* Install vCenter.
|
||||
* Configure vCenter.
|
||||
* Create Datacenter.
|
||||
* Create vCenter cluster.
|
||||
* Add ESXi hosts to clusters in vCenter.
|
||||
|
||||
For more information, see the VMware vSphere documentation.
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
.. _vsphere_upload_iso:
|
||||
|
||||
Upload the Fuel ISO to the VMware vSphere datastore
|
||||
---------------------------------------------------
|
||||
|
||||
You need to download the `Fuel ISO <https://www.fuel-infra.org/#fuelget>`_
|
||||
and upload it do a vSphere datastore.
|
||||
|
||||
**To upload the Fuel ISO to the VMware vSphere datastore:**
|
||||
|
||||
#. Log into the vSphere web client.
|
||||
#. Click **vCenter**.
|
||||
#. Go to the Datastores and choose your datastore.
|
||||
#. Go to the Actions menu and select **Browse Files**.
|
||||
#. Click the **Upload Files** icon, browse your filesystem,
|
||||
and select your Mirantis ISO.
|
||||
#. Proceed to :ref:`vsphere_configure_network`.
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
.. _vsphere_verify_master:
|
||||
|
||||
Verify the Fuel Master node operation
|
||||
-------------------------------------
|
||||
|
||||
You need to verify that the Fuel Master node operates correctly.
|
||||
|
||||
**To verify the Fuel Master node operation:**
|
||||
|
||||
#. Create a new VM on the same ESXi host.
|
||||
#. Boot the created VM via PXE.
|
||||
|
||||
If the boot is successful,
|
||||
the "Total nodes" at the top right of the Fuel Web UI will increase
|
||||
its value after two to five minutes.
|
||||
|
||||
**To verify that the Fuel bootstrap node runs on ESXi:**
|
||||
|
||||
#. Open the node information window in the Fuel Web UI.
|
||||
#. Verify that the **Manufacturer** field says **VMWARE**.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
.. raw:: pdf
|
||||
|
||||
PageBreak oneColumn
|
||||
|
||||
.. _vsphere_intro:
|
||||
|
||||
Install Fuel on VMware vSphere
|
||||
==============================
|
||||
|
||||
This section describes how to configure your VMware vSphere environment
|
||||
to install Fuel.
|
||||
|
||||
This section includes the following topics:
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 3
|
||||
|
||||
vsphere/vsphere_prereq
|
||||
vsphere/vsphere_configure_esxi_networking
|
||||
vsphere/vsphere_upload_iso
|
||||
vsphere/vsphere_configure_network
|
||||
vsphere/vsphere_create_vm
|
||||
vsphere/vsphere_mount_iso
|
||||
vsphere/vsphere_install_master
|
||||
vsphere/vsphere_boot_master
|
||||
vsphere/vsphere_verify_master
|
||||
Loading…
Reference in New Issue