openstack/fuel-docs
Code Issues Proposed changes

Sync Mitaka branch with latest changes

Browse Source 
Change-Id: I20d612862d3a30095a19b549a440b40ea3098022
This commit is contained in:
Olena Logvinova
2016-11-09 15:45:18 +02:00
parent 30d90cb809
commit ec8d9fee24
117 changed files with 4025 additions and 1021 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
userdocs/fuel-install-guide.rst
View File

@@ -13,5 +13,6 @@ Fuel Installation Guide
fuel-install-guide/bootstrap_intro
fuel-install-guide/plugins_intro
fuel-install-guide/vsphere_intro
fuel-install-guide/update-fuel
fuel-install-guide/upgrade_intro
fuel-install-guide/preinstall_intro

9
userdocs/fuel-install-guide/bootstrap/bootstrap_add_package.rst
View File

@@ -25,6 +25,15 @@ the connected external repository through the ``fuel-bootstrap`` builder script.
...
Bootstrap image a778efad-88ca-41fe-b592-f02101c11d22 has been built: /root/example1/a778efad-88ca-41fe-b592-f02101c11d22.tar.gz
You can also specify a path to a custom configuration file with parameters
for building a new bootstrap instead of using parameters from the default
configuration file.
For example:
.. code-block:: console
$ fuel-bootstrap build --config /etc/fuel-bootstrap-cli/my-config-xenial.yaml
#. After the build process is completed, you can import and activate the new bootstrap image:

10
userdocs/fuel-install-guide/bootstrap/bootstrap_builder.rst
View File

@@ -20,12 +20,12 @@ 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]
usage: fuel-bootstrap [--version] [-v] [--log-file <LOG_FILE>] [-q] [-h]
[--debug] [--config <CONFIG_FILE>]
.. list-table:: **Optional arguments**
:widths: 10 25
:widths: 15 25
:header-rows: 0
* - Option
@@ -34,7 +34,7 @@ You can configure Fuel bootstrap images using the ``fuel-bootstrap`` command:
- Shows a program's version number and exits.
* - ``-v``, ``--verbose``
- Increases a verbosity of output. Can be repeated.
* - ``--log-file LOG_FILE``
* - ``--log-file <LOG_FILE>``
- Specify a file to log output. Disabled by default.
* - ``-q``, ``--quiet``
- Suppress output except for warnings and errors.
@@ -42,6 +42,8 @@ You can configure Fuel bootstrap images using the ``fuel-bootstrap`` command:
- Shows this help message and exits.
* - ``--debug``
- Shows tracebacks on errors.
* - ``--config <CONFIG_FILE>``
- Specify a configuration file with bootstrap settings.
.. list-table:: **Commands to operate with a bootstrap image**

2
userdocs/fuel-install-guide/bootstrap/bootstrap_inject_cert.rst
View File

@@ -8,7 +8,7 @@ a bootstrap using ``fuel-bootstrap``.
For example, you can add custom certificates to access
an https repository.
** To inject certificate files:**
**To inject certificate files:**
#. Add a certificate to the Fuel Master system to provide
correct work of debootstrap run on the Fuel Master node:

1
userdocs/fuel-install-guide/install/install_login_fuel_master_node.rst
View File

@@ -81,3 +81,4 @@ initial configuration.
.. seealso::
- :ref:`Log in to the Fuel Master node with multiple NICs <install_login_fuel_master_node_multiple_nics>`
- :ref:`update_fuel`

2
userdocs/fuel-install-guide/install/install_login_fuel_master_node_multiple_nics.rst
View File

@@ -23,4 +23,4 @@ NIC.
.. seealso::
- :ref:`install_login_fuel_master_node`
- :ref:`update_fuel`

4
userdocs/fuel-install-guide/install_install_fuel.rst
View File

@@ -29,3 +29,7 @@ This section includes the following topics:
install/install_login_fuel_master_node
install/install_login_fuel_master_node_multiple_nics
install/install_boot_slave_nodes
.. seealso::
* :ref:`update_fuel`

10
userdocs/fuel-install-guide/sysreq/sysreq_fuel_slave_node_hw_recs.rst
View File

@@ -36,6 +36,16 @@ General guidelines for the Fuel Slave nodes:
nodes. Therefore, the storage configuration for every deployment will
vary significantly.
* Telemetry - MongoDB nodes
Fuel deploys MongoDB version 2.6 with a replica set. To install Telemetry
with the MongoDB database, we recommend that you add three dedicated nodes.
You can also configure one MongoDB role for each controller node.
Since a MongoDB node is configured in the polling mode, you cannot add
more than seven MongoDB nodes. This is a MongoDB limitation for voting
replica set members, and it is not controlled by Fuel. For more details,
see `MongoDB documenation <https://docs.mongodb.com>`_.
.. seealso::
- `OpenStack Architecture Design Guide

11
userdocs/fuel-install-guide/sysreq/sysreq_network_requirements.rst
View File

@@ -152,14 +152,15 @@ The requirements for Public, Storage, and Management networks are:
Neutron L2 and L3 requirements are:
* Each project's network requires one unique VLAN ID.
* Internal network must be isolated from both private and public networks
for security reasons.
* Each project's network requires one unique VLAN ID (using VLAN segmentation) or
unique segmentation ID (using GRE or VxLAN)
* Admin project network is isolated from both private and public networks for
security reasons.
* For floating network each defined project, including the Admin project,
requires one IP address from the floating IP address range.
This IP address goes to the virtual interface of the project's virtual router.
* Each VM instance connected to the external network requires one IP address
from the floating IP range.
* Direct connection to the external network requires one IP address from the
floating IP range for each VM.
* The floating IP address range should not intersect with the Public network
address ranges.
* Specify addresses for the guest OS DNS servers if you do not want to use

73
userdocs/fuel-install-guide/update-fuel.rst Normal file
View File

@@ -0,0 +1,73 @@
.. _update_fuel:
============================
Update Fuel to latest Mitaka
============================
A number of the Fuel Newton features are back-ported to Mitaka after
the Fuel Mitaka release. You can update the Fuel Master node to consume
these features.
**To update the Fuel Master node from the initially released Mitaka to the latest Mitaka version:**
#. Log in to the Fuel Master node CLI as root.
#. Verify that the update repository, for example, ``mos-update``, is available
in the list of your repositories:
.. code-block:: console
cat /etc/yum.repos.d/mos-updates.repo
If the update repository is unavailable, run:
.. code-block:: console
yum-config-manager --add-repo=http://mirror.fuel-infra.org/mos-repos/centos/mos9.0-centos7/updates/x86_64/
rpm --import http://mirror.fuel-infra.org/mos-repos/centos/mos9.0-centos7/updates/RPM-GPG-KEY-mos9.0
#. Clean the YUM cache:
.. code-block:: console
yum clean all
#. Install a code-based integrity check tool Cudet. This tool also includes
the necessary update commands for ``fuel2``:
.. code-block:: console
yum install python-cudet
#. Prepare the Fuel Master node for the Noop run:
.. code-block:: console
update-prepare prepare master
This command installs new ``fuel-nailgun`` and ``fuel-astute``
packages on the Fuel Master node. Also, it executes Nailgun ``dbsync``
and restarts the ``astute`` and ``nailgun`` services.
If any ``fuel-nailgun`` extension is already installed on the Fuel Master node, the
``update-prepare`` script does not restart the Nailgun services.
You should restart the Nailgun services manually using the following
command:
.. code-block:: console
systemctl restart assassind nailgun oswl_flavor_collectord \
oswl_image_collectord oswl_keystone_user_collectord \
oswl_tenant_collectord oswl_vm_collectord oswl_volume_collectord \
receiverd statsenderd
#. Update the Fuel Master node packages, services, and configuration:
.. code-block:: console
update-prepare update master
.. warning:: During the update procedure, the Fuel Master node services
will be restarted automatically.
The script calls ``yum update`` and then runs Puppet tasks to update
the Fuel Master node.

179
userdocs/fuel-install-guide/upgrade/upgrade-apply-patches.rst
View File

@@ -1,179 +0,0 @@
.. _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.
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.

123
userdocs/fuel-install-guide/upgrade/upgrade-fuel.rst
View File

@@ -1,123 +0,0 @@
.. _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>
**Example:**
.. code-block:: console
$ octane fuel-backup --to /tmp/fuel-backup.7.0.tar.gz
#. 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
--admin-password ADMIN_PASSWORD
#. 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>`.

18
userdocs/fuel-install-guide/upgrade/upgrade-internals.rst
View File

@@ -1,10 +1,10 @@
.. _upgrade-internals:
Overview of the Fuel upgrade process
------------------------------------
========
Overview
========
The upgrade is implemented with three upgrade engines, which are python
The upgrade is implemented with upgrade engines, which are python
modules:
* **Host system engine:**
@@ -13,16 +13,6 @@ modules:
#. 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.

36
userdocs/fuel-install-guide/upgrade/upgrade-liberty.rst Normal file
View File

@@ -0,0 +1,36 @@
.. _upgrade_liberty:
==============================
Upgrade Fuel Liberty to Mitaka
==============================
You can upgrade the Fuel Master node from Liberty to Mitaka.
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.
#. Back up the Fuel Master node as described in :ref:`back-up-fuel`.
#. Power off the Fuel Master node.
#. Restore the Fuel Master node as described in :ref:`restore-fuel`.
#. 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.
When Fuel completes the upgrade procedure, the *New Release available*
message appears in the :guilabel:`Releases` tab.
Now, you can update to the latest Mitaka version that includes some features
back-ported from Newton after the Mitaka release.
.. seealso::
* :ref:`update_fuel`
* :ref:`install_configure_bootstrap`

2
userdocs/fuel-install-guide/upgrade/upgrade-local-repo.rst
View File

@@ -35,7 +35,7 @@ or through Fuel CLI using the ``fuel-createmirror`` script.
fuel-createmirror --password PASSWORD
#. Restart the the docker daemon
#. Restart the docker daemon
::

79
userdocs/fuel-install-guide/upgrade_intro.rst
View File

@@ -1,87 +1,20 @@
.. 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 |
+----------------------+------------------------+--------------------------+
If you have a functional Fuel installation, you can upgrade the Fuel software
to the latest version without reinstalling your environments.
This section includes the following topics.
.. toctree::
:maxdepth: 3
:maxdepth: 1
upgrade/upgrade-fuel
upgrade/upgrade-internals
upgrade/upgrade-liberty
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.

6
userdocs/fuel-user-guide/cli.rst
View File

@@ -16,7 +16,7 @@ when you install Fuel. Using the Fuel CLI you can:
your environment if not used carefully.
Modifications that you make using the Fuel CLI take precedence over the
settings applied from the Fuel Web UI. If a change has been applied using
settings applied from the Fuel web UI. If a change has been applied using
the Fuel CLI, Fuel displays the corresponding message in the Fuel web UI.
This section includes the following topics:
@@ -24,11 +24,13 @@ This section includes the following topics:
.. toctree::
:maxdepth: 3
cli/cli_comparison_matrix.rst
cli/cli_acronyms.rst
cli/cli_basic_usage.rst
cli/cli_client_config_file.rst
cli/cli_management.rst
cli/cli_environment.rst
cli/cli_provision.rst
cli/cli_deploy.rst
cli/cli_network.rst
cli/cli_network_group.rst
@@ -37,9 +39,11 @@ This section includes the following topics:
cli/cli_nodes.rst
cli/cli_node_group.rst
cli/cli_roles.rst
cli/cli_nodes_empty_role.rst
cli/cli_plugins.rst
cli/cli_graphs.rst
cli/cli_config_openstack.rst
cli/cli_config_openstack_services_workflow.rst
cli/cli_change_ip_range.rst
cli/cli_modify_environment.rst
cli/cli_noop.rst

36
userdocs/fuel-user-guide/cli/cli_acronyms.rst
View File

@@ -1,26 +1,23 @@
.. _cli-acronyms:
===========================================
Interpretation of acronyms in Fuel commands
-------------------------------------------
===========================================
CLI commands contain a number
of acronyms.
For better understanding of those,
see the example command output below.
.. include:: /userdocs/snippets/notes/deprecated-cli-v1.rst
Fuel CLI commands contain a number of acronyms. For a better understanding of
those, see the example command output below.
.. note:: Nailgun populates the database
with hardware configuration information
about all the managed nodes it discovers
as well as the configuration and status of each node.
The ``fuel node list`` command is used on the Fuel Master node
to list out the current information about the nodes
for the environment:
The :command:`fuel node list` command is used on the Fuel Master node to list out
the current information about the nodes for the environment:
::
.. code-block:: console
[root@fuel ~]# fuel nodes
@@ -87,13 +84,12 @@ The meaning of these fields is:
The following two columns appear at the right end of this display;
they are not shown here:
:pending_roles: Before deployment, lists the roles that have been assigned to this node.
When deployment is complete,
the contents of this field are moved to the **roles** column
:pending_roles: Before deployment, lists the roles that have been assigned
to this node. When deployment is complete, the contents
of this field are moved to the **roles** column.
For Release 6.x and later,
this field can also contain the **primary** value
to indicate that this node is the Primary Controller node.
This field can also contain the **primary** value
to indicate that this node is the primary controller node.
The **primary** value is persisted in the database
through the use of the **has_primary** field
in the ``openstack.yaml`` file.
@@ -106,7 +102,5 @@ they are not shown here:
:group_id: The group node identifier.
When you assign roles to your target nodes,
Fuel tries to automatically determine the node's group based on the DHCP address.
Fuel tries to automatically determine the node's group based on
the DHCP address.

5
userdocs/fuel-user-guide/cli/cli_basic_usage.rst
View File

@@ -1,7 +1,10 @@
.. _cli_basic_usage:
===========
Basic usage
-----------
===========
.. include:: /userdocs/snippets/notes/deprecated-cli-v1.rst
Use the following usage pattern for Fuel commands:

7
userdocs/fuel-user-guide/cli/cli_change_ip_range.rst
View File

@@ -1,9 +1,10 @@
.. _cli_change_ip_range:
==================
Add network ranges
------------------
==================
.. include:: /userdocs/snippets/notes/deprecated-cli-v1.rst
To add network ranges, edit the network configuration file:
add the IP network range to ``ip_ranges`` and change

5
userdocs/fuel-user-guide/cli/cli_client_config_file.rst
View File

@@ -1,7 +1,10 @@
.. _cli-client-config-file:
======================================
Modify the Fuel CLI configuration file
--------------------------------------
======================================
.. include:: /userdocs/snippets/notes/deprecated-cli-v1.rst
The Fuel CLI uses the ``fuel_client.yaml`` file as a source for default
settings. By default, Fuel stores the ``fuel_client.yaml`` file in the

118
userdocs/fuel-user-guide/cli/cli_comparison_matrix.rst Normal file
View File

@@ -0,0 +1,118 @@
.. _cli_comparison_matrix:
===================================
Fuel CLI commands comparison matrix
===================================
The Fuel command-line interface has been changed to simplify usage
and improve user experience. Some of the keys and options have been modified
as well. Although the old ``fuel`` commands are still available, we recommend that
you use the new ``fuel2`` commands instead. The following table describes
new ``fuel2`` commands and their alternatives in the ``fuel`` CLI.
.. csv-table:: **Fuel CLI commands comparison matrix**
:header: Command in ``fuel2`` CLI, Description, Alternative in ``fuel`` CLI
:widths: 8, 7, 7
``fuel2 complete``, Print the completion of a command in CLI, None
``fuel2 help``, Print a detailed help for all commands, ``fuel <cmd> --help``
``fuel2 env add nodes``, Add nodes to an environment with specified roles, ``fuel node --set``
``fuel2 env create``, Create an environment with given attributes, ``fuel env --create``
``fuel2 env delete``, Delete an environment with a given ID, ``fuel env --delete``
``fuel2 env deploy``, Deploy changes on a specified environment, ``fuel deploy-changes``
``fuel2 env deployment-facts delete``, Delete current deployment facts, ``fuel deployment --delete``
``fuel2 env deployment-facts download``, Download the user-defined deployment facts, ``fuel deployment --download``
``fuel2 env deployment-facts get-default``, Download the default deployment facts, ``fuel deployment --default``
``fuel2 env deployment-facts upload``, Upload deployment facts, ``fuel deployment --upload``
``fuel2 env extension disable``, Disable specified extensions for an environment with a given ID, None
``fuel2 env extension enable``, Enable specified extensions for an environment with a given ID, None
``fuel2 env extension list``, Show a list of all available extensions, None
``fuel2 env extension show``, Show a list of enabled extensions for an environment with a given ID, None
``fuel2 env list``, Show a list of all available environments, ``fuel env``
``fuel2 env network download``, Download and store network configuration of an environment, ``fuel network --download``
``fuel2 env network upload``, Upload network configuration and apply it to an environment, ``fuel network --upload``
``fuel2 env network verify``, Run network verification for a specified environment, ``fuel network --verify``
``fuel2 env nodes deploy``, Deploy specified nodes for a specified environment, ``fuel node --deploy``
``fuel2 env nodes provision``, Provision specified nodes for a specified environment, ``fuel node --provision``
``fuel2 env provisioning-facts delete``, Delete current provisioning facts, ``fuel provisioning --delete``
``fuel2 env provisioning-facts download``, Download the user-defined provisioning facts, ``fuel provisioning --download``
``fuel2 env provisioning-facts get-default``, Download the default provisioning facts, ``fuel provisioning --default``
``fuel2 env provisioning-facts upload``, Upload provisioning facts, ``fuel provisioning --upload``
``fuel2 env redeploy``, Redeploy changes on a specified environment, ``fuel redeploy-changes``
``fuel2 env remove nodes``, Remove nodes from an environment, ``fuel node remove``
``fuel2 env reset``, Reset a deployed environment, ``fuel reset``
``fuel2 env settings download``, Download and store an environment settings, ``fuel settings --download``
``fuel2 env settings upload``, Upload and apply an environment settings, ``fuel settings --upload``
``fuel2 env show``, Show information about environment with a given ID, None
``fuel2 env spawn-vms``, Provision a specified environment, None
``fuel2 env stop-deployment``, Stop deployment process for a specific environment, ``fuel stop``
``fuel2 env update``, Change given attributes for an environment, ``fuel env --set``
``fuel2 fuel-version``, Show the current version of Fuel, ``fuel --fuel-version``
``fuel2 graph download``, Download a deployment graph configuration, ``fuel env --deployment-tasks --download``
``fuel2 graph execute``, Start a deployment with a given graph type, None
``fuel2 graph list``, List deployment graphs, None
``fuel2 graph upload``, Upload a deployment graph configuration, ``fuel env --deployment-tasks --upload``
``fuel2 network-group create``, Create a new network group, ``fuel network-group --create``
``fuel2 network-group delete``, Delete a specified network group, ``fuel network-group --delete``
``fuel2 network-group list``, List all network groups, ``fuel network-group``
``fuel2 network-group show``, Show a specified network group, None
``fuel2 network-group update``, Set parameters for a specified network group, ``fuel network-group --set``
``fuel2 network-template delete``, Delete the network template of a specified environment, ``fuel network-template --delete``
``fuel2 network-template download``, Download the network configuration for a specified environment, ``fuel network-template --download``
``fuel2 network-template upload``, Upload the network configuration for a specified environment, ``fuel network-template --upload``
``fuel2 node ansible-inventory``, Generate an ansible inventory file based on the nodes list, None
``fuel2 node attributes-download``, Download attributes of a specified node, None
``fuel2 node attributes-upload``, Upload attributes of a specified node, None
``fuel2 node create-vms-conf``, Create the VMs configuration in metadata for a specified node, None
``fuel2 node disks download``, Download and store configuration of disks for a node to a file, ``fuel node --disk --download``
``fuel2 node disks get-default``, Download the default configuration of disks for a node to a file, ``fuel node --disk --default``
``fuel2 node disks upload``, Upload a stored configuration of disks for a node from a file, ``fuel node --disk --upload``
``fuel2 node interfaces download``, Download and store a configuration of interfaces for a node to a file, ``fuel node --network --download``
``fuel2 node interfaces get-default``, Download the default configuration of interfaces for a node to a file, ``fuel node --network --default``
``fuel2 node interfaces upload``, Upload the stored configuration of interfaces for a node from a file, ``fuel node --network --download``
``fuel2 node label delete``, Delete specific labels on nodes, None
``fuel2 node label list``, Show a list of all labels, None
``fuel2 node label set``, Create or update specific labels on nodes, None
``fuel2 node list``, Show a list of all available nodes, ``fuel node``
``fuel2 node list-vms-conf``, Show a list of VMs for a node, None
``fuel2 node show``, Show information about a node with a given ID, None
``fuel2 node undiscover``, Remove nodes from a database, ``fuel node --delete-from-db``
``fuel2 node update``, Change a node name and/or host name, ``fuel node --name <NEW_NAME>`` and/or ``fuel node --hostname <NEW_HOSTNAME>``
``fuel2 openstack-config delete``, Delete an OpenStack configuration with a given ID, ``fuel openstack-config --delete``
``fuel2 openstack-config download``, Download a specified OpenStack configuration file, ``fuel openstack-config --download``
``fuel2 openstack-config execute``, Execute an OpenStack configuration deployment, ``fuel openstack-config --execute``
``fuel2 openstack-config list``, List all OpenStack configurations, ``fuel openstack-config --list``
``fuel2 openstack-config upload``, Upload a new OpenStack configuration from file, ``fuel openstack-config --upload``
``fuel2 plugins list``, Show a list of all available plugins, ``fuel plugins --list``
``fuel2 plugins sync``, Synchronize plugins on a file system with plugins in the API service, ``fuel plugins --sync``
``fuel2 release component list``, Show a list of components for a given release, None
``fuel2 release list``, Show a list of all available releases, ``fuel release``
``fuel2 release repos list``, Show repositories for a given release, None
``fuel2 release repos update``, Update repositories for a given release, None
``fuel2 role create``, Create a role from a file description, ``fuel role --rel 1 --create``
``fuel2 role delete``, Delete a role from an OpenStack release, ``fuel role --delete``
``fuel2 role download``, Download a full role description to a file, ``fuel role --file``
``fuel2 role list``, Show a list of all available roles for a release, ``fuel role``
``fuel2 role update``, Update a role description from a file, ``fuel role --update``
``fuel2 sequence create``, Create a new deployment sequence, None
``fuel2 sequence upload``, Upload a new deployment sequence, None
``fuel2 sequence download``, Download a deployment sequence data, None
``fuel2 sequence delete``, Delete an existing sequence, None
``fuel2 sequence update``, Update an existing sequence, None
``fuel2 sequence list``, Show a list of all existing sequences, None
``fuel2 sequence show``, Display information about a sequence, None
``fuel2 sequence execute``, Execute a sequence on a specified environment, None
``fuel2 snapshot create``, Generate a diagnostic snapshot, ``fuel snapshot``
``fuel2 snapshot create -c/--config``, Generate a diagnostic snapshot with a custom configuration, ``fuel snapshot < config_file.yml``
``fuel2 snapshot get-default-config``, Download the default configuration to generate a custom diagnostic snapshot, ``fuel snapshot --conf > config_file.yml``
``fuel2 snapshot get-link``, Show the link to download diagnostic snapshot, None
``fuel2 task delete``, Delete a task with a given ID, ``fuel task --delete``
``fuel2 task deployment-info download``, Save a task deployment information to a file, None
``fuel2 task history show``, Show a deployment history about a task with a given ID, None
``fuel2 task list``, Show a list of all available tasks, None
``fuel2 task network-configuration download``, Save a task network configuration to a file, None
``fuel2 task settings download``, Download and save a task settings to a file, None
``fuel2 task show``, Show information about a task with a given ID, None
``fuel2 vip create``, Create a VIP, ``fuel vip --create``
``fuel2 vip download``, Download a configuration of VIPs, ``fuel vip --download``
``fuel2 vip upload``, Upload a new configuration of VIPs from a file, ``fuel vip --upload``

43
userdocs/fuel-user-guide/cli/cli_config_openstack.rst
View File

@@ -1,7 +1,10 @@
.. _cli-config-openstack-services:
==================================================
Modify the configuration of the OpenStack services
--------------------------------------------------
==================================================
.. include:: /userdocs/snippets/notes/deprecated-cli-v1.rst
You can customize the hardcoded, or provided by Nailgun,
configuration values, as well as introduce new configuration options
@@ -23,30 +26,28 @@ defined.
#. Log in to the Fuel Master node.
#. Edit the ``.yaml`` file with the configuration options of the services that
you want to change.
you want to change.
**Example:**
::
.. code-block:: yaml
.. code-block:: yaml
configuration:
nova_config:
DEFAULT/debug:
value: True
DEFAULT/amqp_durable_queues:
value: False
keystone_config:
DEFAULT/default_publisher_id:
ensure: absent
DEFAULT/crypt_strength:
value: 6000
configuration:
nova_config:
DEFAULT/debug:
value: True
DEFAULT/amqp_durable_queues:
value: False
keystone_config:
DEFAULT/default_publisher_id:
ensure: absent
DEFAULT/crypt_strength:
value: 6000
#. Upload the ``.yaml`` file:
* To upload the changes for an OpenStack environment:
.. code-block:: console
fuel openstack-config --env <env_id> --upload file.yaml
@@ -55,7 +56,7 @@ defined.
.. code-block:: console
fuel openstack-config --env <env_id> --role compute \
fuel openstack-config --env <env_id> --role compute \
--upload <file.yaml>
* To upload the changes for selected nodes:
@@ -86,6 +87,7 @@ defined.
fuel openstack-config --env <env_id> --node 1,2,3 --execute
The services will restart automatically.
#. Optionally, run these additional commands:
#. List the configuration changes history:
@@ -94,6 +96,9 @@ defined.
fuel openstack-config --env <env_id> --list
.. note:: The :option:`--list` parameter shows historical data only
for the active configuration.
#. Download the previously uploaded ``.yaml`` file with the configuration
changes:
@@ -103,7 +108,7 @@ defined.
fuel openstack-config --env <env_id> --list
#. Download the ``.yaml`` file:
#. Download the ``.yaml`` file:
.. code-block:: console

35
userdocs/fuel-user-guide/cli/cli_deploy.rst
View File

@@ -1,24 +1,31 @@
.. _cli-deploy:
===================
Deployment commands
-------------------
===================
The following table describes the deployment commands
available in the Fuel CLI.
.. include:: /userdocs/snippets/notes/deprecated-cli-v1.rst
The following table describes the usage of the :command:`fuel deployment`
command available in the Fuel CLI.
.. list-table:: **Deployment commands**
:widths: 10 10 20
:widths: 7 10
:header-rows: 1
* - Description
- Command
- Example
* - Deploy an OpenStack environment.
- ``fuel --env <env_id> deploy-changes``
-
* - Deploy specific nodes.
- ``fuel node --deploy --node <node1_id>,<node2_id>``
-
* - Provision specific nodes.
- ``fuel node --provision --node <node1_id>,<node2_id>``
-
* - Delete current deployment data
- ``fuel --env <ENV> deployment --delete``
* - Download current deployment data
- ``fuel --env <ENV> deployment --download``
* - Download default deployment data
- ``fuel --env <ENV> deployment --default``
* - Get default deployment information for specific nodes
- ``fuel --env <ENV> deployment --default --node <NODE_ID [NODE_ID ...]>``
* - Upload provisioning deployment to a specific directory
- ``fuel --env <ENV> deployment -u --dir path/to/directory``
* - Download deployment information to a specific directory
- ``fuel --env <ENV> deployment -d --dir path/to/directory``

20
userdocs/fuel-user-guide/cli/cli_environment.rst
View File

@@ -1,7 +1,10 @@
.. _cli-environment:
====================
Environment commands
--------------------
====================
.. include:: /userdocs/snippets/notes/deprecated-cli-v1.rst
The following table describes environment management commands
available in the Fuel CLI.
@@ -17,28 +20,27 @@ available in the Fuel CLI.
- ``fuel env``
-
* - Create an environment.
- ``fuel env create --name <env_name> --rel <release_number>``
- ``fuel env create --name <ENV_NAME> --rel <RELEASE_NUMBER>``
- By default, Fuel creates an OpenStack environment in the
``multinode`` mode, and the ``nova`` network mode.
To specify other modes, you can add optional arguments:
::
.. code-block:: console
fuel env create --name <env_name> --rel <release_number> \
fuel env create --name <ENV_NAME> --rel <RELEASE_NUMBER> \
--mode ha --network-mode neutron --net-segment-type vlan
Use the ``set`` action to change the name, mode, or network mode
for an OpenStack environment:
::
.. code-block:: console
fuel --env <env_id> env set --name <NewEmvName> --mode ha_compact
fuel --env <ENV_ID> env set --name <NEW_ENV_NAME> --mode ha_compact
* - Delete an OpenStack environment.
- ``fuel --env <env_id> env delete``
- ``fuel --env <ENV_ID> env delete``
-
* - Update the OpenStack environment to a newer version. To roll back a
failed update, use the same command with the previous release number.
- ``fuel env --update --env <env_id> --rel <release_number>``
- ``fuel env --update --env <ENV_ID> --rel <RELEASE_NUMBER>``
-

22
userdocs/fuel-user-guide/cli/cli_graphs.rst
View File

@@ -1,13 +1,11 @@
.. _cli-graphs:
=====================================
Deployment graphs management commands
-------------------------------------
=====================================
The following table describes the deployment graphs management commands
supported by the Fuel CLI v2. To execute these commands, you need to have
the Fuel CLI installed as described in `Install the OpenStack
command-line clients <http://docs.openstack.org/user-guide/common/cli_install_openstack_command_line_clients.html>`_.
No additional configuration is required.
supported by the Fuel CLI.
.. list-table:: **Deployment graphs management commands**
:widths: 15 20
@@ -25,7 +23,7 @@ No additional configuration is required.
* ``fuel2 graph upload --release <release_id> [--type graph_type] --file tasks.yaml``
* ``fuel2 graph upload --plugin <plugin_id> [--type graph_type] --file tasks.yaml``
| The ``--type`` parameter is optional. If not specified, the default graph is downloaded.
| The ``--type`` parameter is optional. If not specified, the default graph is uploaded.
* - Download deployment graphs from a certain environment. Use the ``--all``, ``--cluster``, ``--release``, or ``plugins`` flag to specify the level of the graphs to download.
- * ``fuel2 graph download --env <env_id> --all [--type <graph_type>] [--file <cluster_graph.yaml>]``
@@ -35,7 +33,17 @@ No additional configuration is required.
| The ``--type`` parameter is optional. If not specified, the default graph is downloaded.
| The graphs downloaded with the keys ``--all`` and ``--plugins`` are the
result of other graphs merge. They are not supposed to be edited and uploaded back,
because, in most cases, they will override further changes in source graphs.
* - Execute deployment graphs. Available for environments only.
- ``fuel2 graph execute --env <env_id> [--type <graph_type>] [--node <node_id>]``
| The ``--type`` parameter is optional. If not specified, the default graph is downloaded.
| The ``--type`` parameter is optional. If not specified, the default graph is downloaded.
* - Run any task graph in a ``noop`` mode to detect customizations.
- ``fuel2 graph execute --env <env_id> [--type <graph_type>] --noop --force``
| The ``--force`` parameter is optional and is necessary for previously
executed graphs or tasks to prevent tasks skipping by Fuel LCM engine.

7
userdocs/fuel-user-guide/cli/cli_management.rst
View File

@@ -1,7 +1,10 @@
.. _cli-management:
========================
Fuel management commands
------------------------
========================
.. include:: /userdocs/snippets/notes/deprecated-cli-v1.rst
The following table describes basic management commands
available in the Fuel CLI.
@@ -19,7 +22,7 @@ available in the Fuel CLI.
.. code-block:: console
fuel <namespace> --help
fuel <namespace> --help
* - View the list of all available releases
- ``fuel release``

49
userdocs/fuel-user-guide/cli/cli_modify_environment.rst
View File

@@ -1,7 +1,10 @@
.. _cli-modify-env:
=========================================
Modify an Openstack environment using CLI
-----------------------------------------
=========================================
.. include:: /userdocs/snippets/notes/deprecated-cli-v1.rst
You can modify your OpenStack environment after deployment
by downloading the ``.yaml`` configuration files, editing settings, and
@@ -9,7 +12,7 @@ then uploading the configuration files back to the Nailgun
server. After uploading the files, you must redeploy your OpenStack
environment.
Before modifying any settings, back up your OpenStack environment
Before modifying any settings, back up your OpenStack environment
configuration.
If you upload any changes for provisioning or deployment operations,
@@ -22,15 +25,49 @@ each node's configuration file and then apply the changes using Fuel CLI.
You can download the following configurations:
* ``network``
* ``settings``
* ``settings``
* ``node --disk``
* ``node --network``
* ``provisioning``
* ``deployment``
.. note::
Operations with ``deployment`` and ``provisioning`` can be node
specific. For example: ``fuel --env 1 deployment --node-id=1,2``.
When performing operations with nodes using :command:`fuel deployment` and
:command:`fuel provisioning` commands, you can indicate specific nodes.
For example:
.. code-block:: console
fuel --env 1 deployment --node 1,2,3
When downloading configurations using :command:`fuel deployment` and
:command:`fuel provisioning` commands, Fuel automatically generates
the following files:
* For deployment:
``master.yaml``
Includes details about the Fuel Master node configuration for a specified
OpenStack environment.
``<NODE_ID>.yaml``
Includes details about the node deployment. The ``<NODE_ID>.yaml`` file
contains deployment details and is identical to the ``astute.yaml`` file
stored on a specific node. The deployment tasks consume parameters
included in ``<NODE_ID>.yaml`` through hiera.
* For provisioning:
``engine.yaml``
Includes credentials for the provisioning service (Cobbler) engine.
``node-<NODE_ID>.yaml``
Includes details about provisioning for each node.
.. seealso::
* :ref:`file-ref`
* :ref:`cli-provision`
* :ref:`cli-deploy`
**To modify an OpenStack environment using CLI:**

11
userdocs/fuel-user-guide/cli/cli_network.rst
View File

@@ -1,7 +1,10 @@
.. _cli-network:
================
Network commands
----------------
================
.. include:: /userdocs/snippets/notes/deprecated-cli-v1.rst
You can manage network configurations using the following command:
@@ -19,7 +22,7 @@ You can manage network configurations using the following command:
- ID of an OpenStack environment
* - ``<PATH>``
- Path to directory
* - <action>
* - ``<action>``
- Action that will be performed for the network configuration.
The following table describes network management commands
@@ -46,9 +49,9 @@ available in the Fuel CLI.
- Upload network configuration for the environment with
ID ``1`` from the current directory:
.. code-block:: console
.. code-block:: console
fuel --env 1 network --upload
fuel --env 1 network --upload
.. note::
The :command:`fuel network` command can update configuration of

5
userdocs/fuel-user-guide/cli/cli_network_group.rst
View File

@@ -1,7 +1,10 @@
.. _cli-network-group:
=================================
Network group management commands
---------------------------------
=================================
.. include:: /userdocs/snippets/notes/deprecated-cli-v1.rst
The following table describes network group management commands
available in the Fuel CLI.

5
userdocs/fuel-user-guide/cli/cli_network_template.rst
View File

@@ -1,7 +1,10 @@
.. _cli-network-template:
====================================
Network template management commands
------------------------------------
====================================
.. include:: /userdocs/snippets/notes/deprecated-cli-v1.rst
The following table describes network template management commands
available in the Fuel CLI.

5
userdocs/fuel-user-guide/cli/cli_nodes.rst
View File

@@ -1,7 +1,10 @@
.. _cli-nodes:
========================
Node management commands
------------------------
========================
.. include:: /userdocs/snippets/notes/deprecated-cli-v1.rst
The following table describes node management commands
available in the Fuel CLI.

148
userdocs/fuel-user-guide/cli/cli_nodes_empty_role.rst Normal file
View File

@@ -0,0 +1,148 @@
.. _cli-nodes-empty-role:
================================
Deploy a node with an empty role
================================
.. include:: /userdocs/snippets/notes/deprecated-cli-v1.rst
You may need to deploy a node with an operating system installed only,
that is an empty role, where you can further deploy your own service
out of Fuel control.
**To deploy a node with an empty role:**
#. Verify available operating systems:
.. code-block:: console
fuel release
**Example of system response:**
.. code-block:: console
id | name | state | operating_system | version
---|----------------------------|-------------|------------------|-----------
2 | Mitaka on Ubuntu 14.04 | available | Ubuntu | mitaka-9.0
3 | Mitaka on Ubuntu+UCA 14.04 | available | Ubuntu | mitaka-9.0
1 | Mitaka on CentOS 6.5 | unavailable | CentOS | mitaka-9.0
Note down the operating system ``id`` you need to install on the node.
#. Verify available nodes:
.. code-block:: console
fuel node
**Example of system response:**
.. code-block:: console
id | status | name | cluster | ip | mac | roles | pending_roles | online | group_id
---|----------|------------------|---------|-----------|-------------------|-------|---------------|--------|---------
2 | discover | Untitled (90:9b) | None | 10.20.0.4 | 08:00:27:f5:90:9b | | | True | None
3 | discover | Untitled (53:f1) | None | 10.20.0.5 | 08:00:27:14:53:f1 | | | True | None
1 | discover | Untitled (7c:11) | None | 10.20.0.3 | 08:00:27:72:7c:11 | | | True | None
#. Create a new environment if you do not have one:
.. code-block:: console
fuel env create --name <ENV_NAME> --release 2
**Example of system response:**
.. code-block:: console
Environment `<ENV_NAME>` with id=1 was created!
#. Verify that the environment has been created:
.. code-block:: console
fuel env
**Example of system response:**
.. code-block:: console
id | status | name | release_id
---|--------|------------|-----------
1 | new | <ENV_NAME> | 2
Note down the ``id`` of the environment.
#. Verify available roles:
.. code-block:: console
fuel role --release 2
**Example of system response:**
.. code-block:: console
name
-------------------
compute-vmware
compute
cinder-vmware
virt
base-os
controller
ceph-osd
ironic
cinder
cinder-block-device
mongo
The role that you need is ``base-os``.
#. Add one of the discovered nodes to the environment with the ``base-os`` role assigned:
.. code-block:: console
fuel node set --env 1 --node 1 --role base-os
**Example of system response:**
.. code-block:: console
Nodes [1] with roles ['base-os'] were added to environment 1
#. Verify the status of the nodes:
.. code-block:: console
fuel node
**Example of system response:**
.. code-block:: console
id | status | name | cluster | ip | mac | roles | pending_roles | online | group_id
---|----------|------------------|---------|-----------|-------------------|-------|---------------|--------|---------
1 | discover | Untitled (7c:11) | 1 | 10.20.0.3 | 08:00:27:72:7c:11 | | base-os | True | 1
2 | discover | Untitled (90:9b) | None | 10.20.0.4 | 08:00:27:f5:90:9b | | | True | None
3 | discover | Untitled (53:f1) | None | 10.20.0.5 | 08:00:27:14:53:f1 | | | True | None
Your node with an empty role has been added to the environment.
.. note::
By default, Fuel does not apply network configuration.
To set up network configuration, run the ``netconfig`` puppet manifests
that comes with ``fuel-library``.
Fuel automatically executes the following tasks on ``base-os`` nodes only:
* ``hiera``
* ``globals``
* ``logging``
See the `tasks.yaml <https://github.com/openstack/fuel-library/blob/master/deployment/puppet/deployment_groups/tasks.yaml#L130>`__
configuration file

49
userdocs/fuel-user-guide/cli/cli_noop.rst Normal file
View File

@@ -0,0 +1,49 @@
.. _cli_noop:
========================================================
Detect custom configurations in an OpenStack environment
========================================================
Before you redeploy, update, or upgrade your OpenStack environment, ensure
that next Fuel tasks run will not override important changes that had been
applied to a whole OpenStack environment or a particular OpenStack node.
This procedure should only be applied to OpenStack nodes with the ``ready``
statuses or to OpenStack environments with the ``operational`` statuses.
**To detect custom configurations using the Fuel task graphs:**
#. Select from the following options:
* If you want to check that an environment has customizations using
a specific graph, execute the graph in the ``noop`` mode:
.. code-block:: console
fuel2 graph execute --env <ENV_ID> --type <GRAPH_TYPE> --noop --force
* If you want to check that particular OpenStack nodes have customizations
using a specific graph, execute this graph in the ``noop`` mode:
.. code-block:: console
fuel2 graph execute --env <ENV_ID> --type <GRAPH_TYPE> -n <NODE_IDs> --noop --force
.. note:: The Puppet Noop run for any OpenStack environment or node
does not change their statuses. The Noop run is an additional
check rather than a part of the deployment process.
* If you want to view the Puppet Noop run reports for a particular task graph,
type one of the following:
.. code-block:: console
fuel deployment-tasks --tid <TASK_ID> --task-name <TASK_NAME> --include-summary
.. code-block:: console
fuel2 task history show <TASK_ID> --include-summary
Reports for each Puppet Noop run are stored on all OpenStack nodes in
the ``/var/lib/puppet/reports/<NODE-FQDN>/<TIMESTAMP>.yaml`` directory
and include details about the changes that were applied to the Fuel task
graphs.

13
userdocs/fuel-user-guide/cli/cli_plugins.rst
View File

@@ -1,7 +1,10 @@
.. _cli_plugins:
==========================
Plugin management commands
--------------------------
==========================
.. include:: /userdocs/snippets/notes/deprecated-cli-v1.rst
The following table describes the plugin management commands
available in the Fuel CLI.
@@ -18,12 +21,12 @@ available in the Fuel CLI.
- Command
- Example
* - Install a Fuel plugin from an ``.fp`` package.
- `` fuel plugins --install <fuel-plugin-file>``
- ``fuel plugins --install <fuel-plugin-file>``
-
* - Install a Fuel plugin from an ``.rpm`` package.
- ``yum install <fuel-plugin-file>``
-
* - Register a Fuel plugin installed using
* - Register a Fuel plugin installed using
``yum install`` from an ``.rpm`` package in Nailgun.
- ``fuel plugins --register <fuel-plugin-name>==<fuel-plugin-version>``
-
@@ -50,7 +53,7 @@ available in the Fuel CLI.
Upgrades are not supported for major versions of plugins installed
from the ``.rpm`` package, as well as for plugins installed from the
``.fp`` packages. For example, you can only upgrade a Fuel plugin
installed from an ``.rpm`` package from version
installed from an ``.rpm`` package from version
1.0.0 to 1.0.1.
- fuel plugins --update <fuel-plugin-file>
- ``fuel plugins --update <fuel-plugin-file>``
-

29
userdocs/fuel-user-guide/cli/cli_provision.rst Normal file
View File

@@ -0,0 +1,29 @@
.. _cli-provision:
=====================
Provisioning commands
=====================
.. include:: /userdocs/snippets/notes/deprecated-cli-v1.rst
The following table describes the usage of the :command:`fuel provisioning`
command available in the Fuel CLI usage.
.. list-table:: **Provisioning commands**
:widths: 7 10
:header-rows: 1
* - Description
- Command
* - Delete current provisioning data
- ``fuel --env <ENV> provisioning --delete``
* - Download current provisioning data
- ``fuel --env <ENV> provisioning --download``
* - Download default provisioning data
- ``fuel --env <ENV> provisioning --default``
* - Get default provisioning information for specific nodes
- ``fuel --env <ENV> provisioning --default --node <NODE_ID [NODE_ID ...]>``
* - Upload provisioning information to a specific directory
- ``fuel --env <ENV> provisioning -u --dir path/to/directory``
* - Download provisioning information to a specific directory
- ``fuel --env <ENV> provisioning -d --dir path/to/directory``

7
userdocs/fuel-user-guide/cli/cli_roles.rst
View File

@@ -1,7 +1,10 @@
.. _cli-roles:
========================
Role management commands
------------------------
========================
.. include:: /userdocs/snippets/notes/deprecated-cli-v1.rst
Fuel CLI implements standard CRUD for operations on a node role.
The following table describes the role management commands
@@ -74,7 +77,7 @@ available in the Fuel CLI.
swift | 17
* - Update the role data
- `` fuel role --rel <release_id> --update --file <file>``
- ``fuel role --rel <release_id> --update --file <file>``
- ::
fuel role --rel <2> --update --file <swift.yaml>

9
userdocs/fuel-user-guide/cli/cli_vip.rst
View File

@@ -1,7 +1,10 @@
.. _cli-vip:
==============================
Virtual IP management commands
------------------------------
==============================
.. include:: /userdocs/snippets/notes/deprecated-cli-v1.rst
The following table describes virtual IP management commands
available in the Fuel CLI.
@@ -22,13 +25,13 @@ available in the Fuel CLI.
* ``<FILE_NAME>`` - a name of the ``yaml`` file where to save a VIP
configuration (optional).
- `` fuel --env <ENV_ID> vip --download --file <FILE_NAME>``
- ``fuel --env <ENV_ID> vip --download --file <FILE_NAME>``
- .. code-block:: console
fuel --env 1 vip --download --file vip.yaml
* - Upload a VIP configuration for a specific environment from a
specified file.
- `` fuel --env <ENV_ID> vip --upload --file <FILE>``
- ``fuel --env <ENV_ID> vip --upload --file <FILE>``
- .. code-block:: console
fuel --env 1 vip --upload --file vip.yaml

6
userdocs/fuel-user-guide/configure-environment.rst
View File

@@ -21,7 +21,7 @@ This section includes the following topics:
PageBreak
.. toctree::
:maxdepth: 3
:maxdepth: 1
configure-environment/add-nodes.rst
configure-environment/add-label.rst
@@ -33,9 +33,13 @@ This section includes the following topics:
configure-environment/selectable-offload.rst
configure-environment/map-logical-to-physical-nic.rst
configure-environment/verify-networks.rst
configure-environment/network-templates.rst
configure-environment/customize-partitions.rst
configure-environment/config-drive-format.rst
configure-environment/settings.rst
configure-environment/dns-ntp-support.rst
configure-environment/configure-multipath.rst
configure-environment/nfv.rst
configure-environment/workflows.rst
configure-environment/enable-usb-discovery.rst
configure-environment/configure-vmware-vcenter-settings.rst

1
userdocs/fuel-user-guide/configure-environment/add-nodes.rst
View File

@@ -43,3 +43,4 @@ For more information, see
- *System requirements* in *Fuel Installation Guide*
- :ref:`add-label-ug`
- :ref:`change-hostname-slave-nodes`
- :ref:`cli-nodes-empty-role`

31
userdocs/fuel-user-guide/configure-environment/configure-vmware-vcenter-settings.rst Normal file
View File

@@ -0,0 +1,31 @@
.. _configure-vmware-vcenter-settings:
=================================
Configure VMware vCenter settings
=================================
If your environment is integrated with VMware vCenter, you can specify a
Certificate Authority (CA) bundle file to use for verifying the VMware vCenter
server certificate for the OpenStack Compute service, OpenStack Block Storage
service, and OpenStack Image service.
**To configure the VMware vCenter certificate verification:**
#. Log in to the Fuel web UI.
#. Navigate to the :guilabel:`VMware` tab.
#. Configure the VMware vCenter certificate verification depending on your
environment needs:
* If you plan to deploy an environment for testing purposes or want to
speed up the deployment process, disable the certificate
verification by selecting
:guilabel:`Bypass vCenter certificate verification` in the
:guilabel:`VMware vCenter Settings` section.
* If VMware vCenter is using a self-signed certificate:
#. In the :guilabel:`CA file` section, upload a custom CA certificate.
#. Leave :guilabel:`Bypass vCenter certificate verification` unchecked.
* To use a VMware vCenter server certificate emitted by a known CA, for
example, GeoTrust, leave the :guilabel:`CA file` section empty and the
:guilabel:`Bypass vCenter certificate verification` unchecked.
#. Click :guilabel:`Save Changes`.

32
userdocs/fuel-user-guide/configure-environment/enable-usb-discovery.rst Normal file
View File

@@ -0,0 +1,32 @@
.. _enable-usb-discovery:
Enable USB devices discovery
----------------------------
When Fuel discovers Fuel Slave nodes, it does not automatically detect USB
devices. However, for testing or other purposes you may need to enable
USB devices discovery.
**To enable USB devices discovery:**
#. Log in to Fuel Master node CLI.
#. Open the ``/etc/fuel-bootstrap-cli/fuel_bootstrap_cli.yaml`` file
for editing.
#. Add ``report_usb_block_devices`` to the ``extend_kopts`` string.
**Example:**
.. code-block:: console
extend_kopts: "biosdevname=0 net.ifnames=1 debug ignore_loglevel
log_buf_len=10M print_fatal_signals=1 LOGLEVEL=8 report_usb_block_devices"
#. Rebuild the bootstrap image:
::
fuel-bootstrap build --activate
#. Reboot all discovered Fuel Slave nodes.
The nodes boot the new bootstrap image.

31
userdocs/fuel-user-guide/configure-environment/network-templates.rst Normal file
View File

@@ -0,0 +1,31 @@
.. _network-templates-intro:
Deploy network configurations using network templates
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
By default, Fuel configures the following networks (Linux bridges): Public,
Private, Storage, Admin (PXE), and Management. In addition, if you install the
OpenStack Bare Metal service, Fuel creates the Baremetal network. If you need
to add a custom network or do not need any of the default networks, you can
configure or delete the required networks through network templates.
Network templates enable you to:
* Create a custom set of networks.
* Create mappings of network roles to networks.
* Use a network on a specific node only if a corresponding node role is
configured on the node
* Implement custom networking topologies, such as sub-interface bonding,
and so on.
This section includes the following topics:
.. toctree::
:maxdepth: 1
network-templates/network-templates-overview.rst
network-templates/network-templates-limitations.rst
network-templates/network-templates-structure.rst
network-templates/network-templates-create.rst
network-templates/network-templates-delete.rst
network-templates/network-templates-examples.rst

29
userdocs/fuel-user-guide/configure-environment/network-templates/examples/one-network.rst Normal file
View File

@@ -0,0 +1,29 @@
.. _one-network:
Configure a single network topology
-----------------------------------
Fuel supports a single network configuration where one network serves
all OpenStack traffic. This configuration is common in
proof of concept deployments where no additional networks are
available.
**To configure a single network:**
#. Save `network template for one network
</developer/fuel-docs/network_templates/one_network.yaml>`_
as ``network_template_<env id>.yaml``.
#. Upload the network template by typing:
::
# fuel network-template --upload --env <env id>
#. Deploy the OpenStack environment.
#. Allocate the correct floating IP pool to the network.
#. Clear the gateway from `router04`.
#. Delete the `admin_floating_net__subnet` subnet.
#. Create a new subnet with the floating IP pool from the single network.
#. Set gateway on `router04`.

75
userdocs/fuel-user-guide/configure-environment/network-templates/examples/two-networks.rst Normal file
View File

@@ -0,0 +1,75 @@
.. _two-networks:
Configure the two-network topology
----------------------------------
Fuel supports two-network configuration where one network is
dedicated for PXE traffic and another network for
all other traffic.
**To configure a two-network topology:**
1. Create a new network for all non-PXE traffic:
::
# fuel network-group --create --name everything --cidr <cidr>
--gateway <gateway> --nodegroup <nodegroup>
2. Set the ``render_addr_mask`` parameter to `internal` for this network by
typing:
::
# fuel network-group --set --network 39 --meta '{"name":
"everything", "notation": "cidr", "render_type": null, "map_priority": 2,
"configurable": true, "use_gateway": true, "render_addr_mask":
"internal", "vlan_start": null, "cidr": "10.108.31.0/24"}'
This parameter is required by the Fuel library. The Fuel library requires
a value called ``internal_address`` for each node.
This value is set to the node's IP address from a network group which has
``render_addr_mask`` set to `internal` in its metadata. Therefore, update
``render_addr_mask`` for this network.
3. Save `network template for two networks
</developer/fuel-docs/network_templates/two_networks.yaml>`_
as ``network_template_<env id>.yaml``.
.. note::
Verify that ``nic_mapping`` matches your configuration.
4. Upload the network template by typing:
::
# fuel network-template --upload --env <env id>
5. Deploy the environment.
6. After Fuel completes the deployment, verify that only one bridge is
configured by typing:
::
# ip -4 a
**Example of system output:**
::
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group
default
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
8: br-fw-admin: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
state UP group default
inet 10.108.5.3/24 brd 10.108.5.255 scope global br-fw-admin
valid_lft forever preferred_lft forever
16: vr-host-base: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast state UP group default qlen 1000
inet 240.0.0.5/30 scope global vr-host-base
valid_lft forever preferred_lft forever
30: hapr-host: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP group default qlen 1000
inet 240.0.0.1/30 scope global hapr-host
valid_lft forever preferred_lft forever

128
userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-create.rst Normal file
View File

@@ -0,0 +1,128 @@
.. _network-templates-create:
Create a network template
-------------------------
You can use one of the network templates provided in
:ref:`network-templates-examples`.
However, if these templates do not meet your networking requirements,
you can create your own. We strongly recommend that you use the
``default.yaml`` network template provided in this documentation to
build your own network template.
.. note::
When you configure a network using a network template, you cannot apply
changes to the nodes network configuration using the Fuel web UI. For
example, if you configure an OpenStack environment using network
templates, deploy the OpenStack environment, and later decide to add
new nodes to that environment, you must update network configuration
of these nodes using a network template and do not use the Fuel web UI.
However, templates do not describe the level 2 and level 3 network
settings. Therefore, you must set them using Fuel web UI, CLI, or API.
After uploading a network template, you must create and/or
delete networks and node groups using the Fuel CLI to reflect the uploaded
network configuration. Otherwise, the configuration specified in the network
template will not take effect and may result in a malfunction.
**To create a network template:**
#. Create a ``.yaml`` file.
#. Specify your network configuration in the ``.yaml`` file following
the conventions described in :ref:`network-templates-structure`.
#. Log in to the Fuel Master node CLI.
#. Display the ID of the environment in which you want to upload the
template:
::
fuel environment
#. Upload the network template to Fuel:
::
fuel --env <ENV_ID> network-template --upload --dir <PATH>
**Example:**
::
fuel --env 1 network-template --upload --dir /home/stack/
#. Add or delete custom networks that you have introduced through
the network template:
* If you need to delete a network:
#. View the ID of the network by typing:
::
fuel network-group
**Example of system response:**
::
id | name | vlan_start | cidr | gateway |group_id
---+---------------+------------+--------------+----------+--------
24 | private | | | | 4
23 | private | | | | 5
22 | storage | 102 | 10.10.1.0/24 | 10.1.1.1 | 5
25 | management | 101 | 10.10.0.0/24 | 10.0.0.1 | 4
21 | public | | 10.10.0.0/24 | 10.10.0.1| 4
#. Delete the required network using the network ID.
::
fuel network-group --delete --env <env_id> --network <network_id>
* If you need to add a new network, type:
::
fuel network-group --create --node-group <node_group_id> --name
<network_name> --vlan <vlan_id> --cidr <cidr_id>
#. Add or delete custom networks as described in
:ref:`cli-network-group`.
#. Configure L2 and L3 network settings:
.. note:: You cannot modify VLAN settings through the Fuel web UI or CLI
Configure VLAN settings in the network template.
* Using Fuel web UI:
#. Log in to the Fuel web UI.
#. Click :guilabel:`Networks`.
#. Configure :guilabel:`Network Settings` as required.
.. note:: If you add additional node network group with different from the
default node network group settings, update the network template
with the required changes.
* Using Fuel CLI:
#. Log in to the Fuel CLI.
#. Download network configuration:
::
fuel --env <env_ID> network --download
#. Make the required changes in the network ``.yaml`` file.
#. Upload the configuration to the Fuel Master node:
::
fuel --env <env_ID> network --upload
.. seealso::
- :ref:`cli-network-group`
- :ref:`cli-network-template`

32
userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-delete.rst Normal file
View File

@@ -0,0 +1,32 @@
.. _network-template-delete:
Delete a network template
-------------------------
You can delete a network template that you have previously uploaded.
.. warning::
Do not delete network templates that are used in your OpenStack
environment as it may result in a failure of the whole network
configuration.
**To delete a network template:**
#. Log in to the Fuel Master node CLI.
#. Type:
::
fuel --env <ENV_ID> network-template --delete
**Example:**
::
fuel --env 1 network-template --delete
.. seealso::
- :ref:`cli-network-group`
- :ref:`cli-network-template`

35
userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-examples.rst Normal file
View File

@@ -0,0 +1,35 @@
.. _network-templates-examples:
Network template examples
=========================
This section provides examples of network configurations
using network templates. You can use the default template
and modify it for your requirements or use any of the templates provided
in the `network templates folder </developer/fuel-docs/network_templates.html>`_.
The following table describes network template examples:
.. list-table:: **Examples of network templates**
:widths: 10 10
:header-rows: 1
* - Template
- Description
* - ``default.yaml``
- The default network template deploys the basic configuration that you
can deploy using the Fuel web UI. You can use this template to create
your own network template. Additional information about network
configuration using network templates provided in the file.
* - ``one_network.yaml``
- A network template that describes a configuration in which one network
serves all traffic.
* - ``two_networks.yaml``
- A network template that describes a configuration in which all traffic
is served by two networks.
.. toctree::
:maxdepth: 1
examples/one-network.rst
examples/two-networks.rst

18
userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-limitations.rst Normal file
View File

@@ -0,0 +1,18 @@
.. _network-templates-limitations:
Network template limitations
----------------------------
When using network templates, consider the following limitations:
* All operations with templates must be performed through CLI or API.
The Fuel web UI does not support network templates.
* The Public network which maps to the External network in OpenStack
cannot be removed.
* When you use network templates, do not download and modify Fuel
deployment configurations using the ``fuel download`` and
``fuel upload`` commands as it may result in a system malfunction.
* Mapping of network roles to networks, as well as network topology cannot
be configured for individual nodes. They can only be set for a node role
or/and node group.
* Network verification in the Fuel web UI has limited support.

17
userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-overview.rst Normal file
View File

@@ -0,0 +1,17 @@
.. _network-templates-overview:
Overview of network templates
-----------------------------
A network template is a ``.yaml`` file that contains network configuration
for an OpenStack environment. To apply custom network
configurations, create and configure
the template according to your environment requirements. For your convenience,
use the following :ref:`network-templates-examples`.
The name of the network template
must follow this convention: ``network_template_<ENV_ID>.yaml``. Verify the
ID of your OpenStack environment by running the ``fuel environment`` command.
For example, if the ID of an OpenStack environment is ``1``, the name of the
template is ``network_template_1.yaml``.

19
userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-structure.rst Normal file
View File

@@ -0,0 +1,19 @@
.. _network-templates-structure:
Structure of network templates
------------------------------
You can use the structure described in this section, as well
as the default template, to create a template that meets the
requirements of your configuration.
Network parameters are defined in the ``adv_net_template``
section in the ``network_template_<ENV_ID>.yaml`` file.
.. toctree::
:maxdepth: 1
network-templates-structure/network_scheme.rst
network-templates-structure/nic_mapping.rst
network-templates-structure/templates_for_node_role.rst
network-templates-structure/network_assignment.rst

27
userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-structure/network_assignment.rst Normal file
View File

@@ -0,0 +1,27 @@
.. _network-assignment:
network_assignment
------------------
**Description**
Describes mapping between endpoints and network names. The **Example**
section describes the mapping that Fuel configures by default
without using templates. The set of networks can be changed
using API.
**Example**
::
network_assignments:
storage:
ep: br-storage
private:
ep: br-prv
public:
ep: br-ex
management:
ep: br-mgmt
fuelweb_admin:
ep: br-fw-admin

200
userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-structure/network_scheme.rst Normal file
View File

@@ -0,0 +1,200 @@
.. _network-scheme:
network_scheme
--------------
**Description**
Defines the name of the network template as well as the following
parameters that are applied to each network that needs to be
configured:
* ``priority`` - defines the order in which the network templates will
be applied to a node. The values range 0 to 64000.
For example, you can set ``100``, ``200``, ``300`` with ``100``
being the highest priority template.
* ``transformations`` - a sequence of actions that builds the required
network configuration. For example: ``add-br`` - add a network
bridge, ``add-port`` - add a network port. The Puppet L23network
module creates network objects described in the ``transformations``
section that connect physical interfaces with logical endpoints. Order
of commands specified in this section is significant.
The sequence of commands that create network configuration must
be reflected in the transformation section:
* For service networks:
#. Create a Linux bridge. By default, if you do not specify a
provider a Linux bridge is created.
#. Create a network port that connects the Linux bridge and the
physical network interface.
* For workload networks:
#. Create an OVS bridge as a first point of connection between
the OpenStack Networking service and the physical network
interface.
#. Create a Linux bridge. Since an OVS bridge cannot directly connect
to a physical interface, a Linux bridge is required.
#. Create a patch that connects Linux and OVS bridges.
#. Create a network port that connects the Linux bridge and the
physical network interface.
You can specify the following commands in the ``transformation``
section:
* ``add-br`` - creates a bridge. By default, creates a Linux
bridge. You can specify the following parameters for this command:
* ``name`` - name of the network bridge. For example, ``br-admin``.
* ``provider`` - a network technology such as Open vSwitch (OVS) or
Linux Bridge, that connects physical interface with
the OpenStack Networking service. Default provider is Linux
Bridge. The options are: ``linux``, ``ovs``.
* ``mtu`` - (optional) enables you to specify MTU for this network bridge.
* ``add-port`` - create a port that connects a Linux bridge with a
physical network interface. You can specify the following parameters
for this command:
* ``name`` - name of the network port.
* ``bridge`` - name of the bridge for which the port is created.
* ``type`` - (optional) A type of the OVS interface for the port.
Default value is ``internal``. Available options include:
``internal``, ``system``, ``tap``, ``gre``, ``null``.
See the OVS documentation for more details. Specify
* ``trunks`` - (optional) a set of 802.1q tags in the form of integers
from 0 to 4095) that are allowed to pass through if the "tag"
option equals 0. Available options include:
* Empty list - all traffic passes
* 0 - untagged traffic only.
* 2-4095 - traffic with the specified tag passes.
For example, 10,10,20.
* ``port_properties`` - (optional) a list of additional OVS port
properties to modify them in OVS database.
* ``interface_properties`` (optional) a list of additional OVS interface
properties to modify them in OVS database.
* ``add-patch`` - connects network bridges. Available parameters include:
* ``bridges`` - a pair of bridges to connect. You can specify either
bridges of the same type or of different types.
* ``peers`` - (optional) abstract names for each end of the patch.
* ``tags`` - (optional) a pair of integers that represent an
802.1q tag of traffic that is captured from a corresponding
OVS bridge. Available values include:
* 0 - only the untagged traffic passes through
* 1-4094 - the bond allows only the traffic with the specific tag.
Specify the tags in the ``trunks`` parameter.
* ``trunks`` - (optional) a set of 802.1q tags in a form of
integers from 2 to 4095 which are allowed to pass through if the
``tag`` parameter is set to ``0``. Available values include:
* Empty list - all traffic passes (default)
* 0 - untagged traffic only
* 2-4095 - traffic with the specified tag passes). For example, 0,10,20.
* ``add-bond`` - combines two or more network interfaces for redundancy
and creates a network object called bond. You can specify
the following parameters for this command:
* ``name`` - name of the network port.
* ``interfaces`` - a set of two or more network interfaces that you
want to bind. For example, ``eth1, eth2``.
* ``bridge`` - name of the bridge on which the bond must be created.
* ``tag`` - (optional) a 802.1q tag of traffic which
received from an OVS bridge. Available values include:
* 0 - the bond ignores the tag and allows all traffic to pass
through.
* 1 - 4094 - the bond allows only the traffic with the specific tag.
Specify the tags in the ``trunks`` parameter.
* ``trunks`` - (optional) a set of 802.1q tags in a form of
integers from 2 to 4095 which are allowed to pass through if the
``tag`` parameter is set to ``0``. Available values include:
* Empty list - all traffic passes (default)
* 0 - untagged traffic only
* 2-4095 - traffic with the specified tag passes). For example, 0,10,20.
* ``properties`` - (optional) a list of additional OVS bonded port
properties to modify them in the OVS database. Use this parameter
to set the aggregation mode and balancing strategy, to configure LACP,
and so on. For more informations, see the OVS documentation.
* ``endpoints`` - lists logical interfaces or bridges
with assigned IP addresses to which you can map one or more network
roles.
* ``roles`` - mapping of a network traffic to a logical endpoint. When you
apply multiple templates to one node, verify that this parameter
in one template does not contradict this parameter in other templates.
The list of supported network traffics (network roles) is available in the
``openstack.yaml`` file on the Fuel Master node. If you have Fuel plugins
installed in your environment, you can also map network traffic related
to the plugin. For the list of types of network traffic related to the
plugin, see the corresponding ``network_roles.yaml`` file in the plugin
repository.
The ``roles`` section cannot be empty. If you do not want to specify any
mappings, you must create one fake mapping. For example:
**Example:**
::
roles:
fake/ext: br-pub-ext
**Example**
::
network_scheme:
storage: <template name>
priority:
...
transformations:
...
endpoints:
...
roles:
...
private: <template name>
priority:
...
transformations:
...
endpoints:
...
roles:
...
.. seealso::
- `Network template spec
<https://specs.openstack.org/openstack/fuel-specs/specs/7.0/networking-templates.html>`_
- `Virtual IP reservation for Fuel plugins
<https://wiki.openstack.org/wiki/Fuel/Plugins#Virtual_IP_reservation_via_Fuel_Plugin.27s_metadata>`_

30
userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-structure/nic_mapping.rst Normal file
View File

@@ -0,0 +1,30 @@
.. _nic-mapping:
nic_mapping
-----------
**Description**
Specifies aliases to the network interface names mapping,
for example, ``adm: eth0``. If a node is not listed in this section,
default mapping applies. You can configure custom mapping for
any node using the node name. The number of NICs depends on the
network topology and may vary. Aliases are optional and if
all nodes have the same number of NICs connected in a similar
manner, you can use NIC names instead.
**Example**
::
nic_mapping:
default:
adm: eth0
pub: eth1
man: eth2
stor: eth3
node-33:
adm: eth0
pub: eth4
man: eth1
stor: eth2

35
userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-structure/templates_for_node_role.rst Normal file
View File

@@ -0,0 +1,35 @@
.. _templates-for-node-role:
templates_for_node_role
-----------------------
**Description**
List of network schemes for every node role used in the environment.
The order of the template names is significant and must be provided
according to your configuration requirements. For example, first
the Puppet module must create a network bridge and then the
corresponding sub-interface and not vice versa. While templates
can be reused for different node roles, each template is executed
once for every node.
When several roles are mixed on one node and no priority is set,
an alphabetical order of node roles is used to determine the final
order of the templates.
**Example**
::
templates_for_node_role:
controller:
- public
- private
- storage
- common
compute:
- common
- private
- storage
ceph-osd:
- common
- storage

9
userdocs/fuel-user-guide/configure-environment/post-deployment-settings.rst
View File

@@ -25,10 +25,9 @@ environment with new parameters.
.. note::
To restore the last successfully deployed OpenStack settings
for your environment, click :guilabel:`Load Deployed`.
The :guilabel:`Load Deployed` button does not display
for the OpenStack environments with the ``new`` status.
To restore the last deployed OpenStack settings for your environment,
click :guilabel:`Load Deployed`. Fuel displays the :guilabel:`Load Deployed`
button only for the successfully deployed OpenStack environments.
#. In the :guilabel:`Dashboard` tab, view :guilabel:`List of changes`
to deploy.
@@ -36,4 +35,4 @@ environment with new parameters.
#. Click :guilabel:`Deploy Changes` to redeploy the OpenStack environment
with the new configuration.
Or click :guilabel:`Discard` to discard the changes and load the last
successfully deployed OpenStack environment configuration.
successfully deployed OpenStack environment configuration.

6
userdocs/fuel-user-guide/configure-environment/select-bootable-device.rst
View File

@@ -16,12 +16,12 @@ By default, Fuel boots the first disk it detects.
* Using the Fuel CLI:
#. Log in to the the Fuel Master node CLI.
#. Log in to the Fuel Master node CLI.
#. Download the configuration file of the node:
.. code-block:: console
fuel node --node-id <node_id> --disks --download
fuel node --node-id <node_id> --disk --download
#. In the ``disks.yaml``, set ``bootable: True`` for the required node's
disk. For example:
@@ -44,4 +44,4 @@ By default, Fuel boots the first disk it detects.
.. code-block:: console
fuel node --node-id <node_id> --disks --upload
fuel node --node-id <node_id> --disk --upload

210
userdocs/fuel-user-guide/configure-environment/settings.rst
View File

@@ -1,12 +1,8 @@
.. raw:: pdf
PageBreak
.. _settings-ug:
============================================
Configure the OpenStack environment settings
--------------------------------------------
============================================
You can configure security, compute, storage, logging, and other
settings in the :guilabel:`Settings` tab. Most of these settings you have
@@ -27,105 +23,127 @@ by editing the corresponding configuration files.
* - Name
- Description
* - **General settings**
- * Access
Enables you to modify access permissions for Horizon.
By default, Fuel assigns user name, password, and tenant *admin*.
* Repositories
Fuel includes default repositories from which it downloads the
packages required to install and update Fuel and OpenStack
components. If you do not have an Internet connection, you can
set
up a local repository and provide the URL to the repository on
this page.
* Kernel parameters
Enables you to modify kernel parameters. This field does not set
kernel
parameters for the Fuel Master node or for nodes that have
already been deployed.
- Access
Enables you to modify access permissions for Horizon.
By default, Fuel assigns user name, password, and tenant *admin*.
Repositories
Fuel includes default repositories from which it downloads the
packages required to install and update Fuel and OpenStack
components. If you do not have an Internet connection, you can
set up a local repository and provide the URL to the repository on
this page.
Kernel parameters
Enables you to modify kernel parameters. This field does not set
kernel parameters for the Fuel Master node or for nodes that have
already been deployed.
* -
- The kernel parameters for OpenStack and Fuel include:
The :guilabel:`Kernel parameters` for OpenStack and Fuel include:
* ``ttys0=<speed>``
Enables serial console for videoless servers.
* ``console=ttyS0,9600``
Enables serial console.
* ``nofb``
Disables Linux framebuffer.
* ``nomodeset``
Disables the video card kernel handling. This parameter may be
required for old integrated server video chips.
* ``intel_iommu and amd_iommu``
Enables/disables physical-to-virtual address translation for
peripheral devices. Some devices, such as Mellanox cards,
require
this parameter to be enabled. Other peripheral devices may be
incompatible with device virtual address space and may only
work
with real address space. If you are unable to boot a node or
the
node has a kernel panic soon after being booted, setting this
parameter to "off" may resolve the issue.
* ``unsupported_hardware``
Instructs the operating system to boot even if it does not
recognize some of the configured hardware. Failure to set
this parameter may result in inability for Linux to boot. This
typically happens with the latest CPU models. Because most
hardware
provides backward compatibility with older versions, setting
this
kernel parameter may enable the system to boot. However, if no
backward compatibility is provided, the system may panic or
fail in other ways even with this parameter set.
``ttys0=<speed>``
Enables serial console for videoless servers.
``console=ttyS0,9600``
Enables serial console.
``nofb``
Disables Linux framebuffer.
``nomodeset``
Disables the video card kernel handling. This parameter may be
required for old integrated server video chips.
``intel_iommu and amd_iommu``
Enables/disables physical-to-virtual address translation for
peripheral devices. Some devices, such as Mellanox cards,
require this parameter to be enabled. Other peripheral devices
may be incompatible with device virtual address space and may only
work with real address space. If you are unable to boot a node or
the node has a kernel panic soon after being booted, setting this
parameter to ``off`` may resolve the issue.
``unsupported_hardware``
Instructs the operating system to boot even if it does not
recognize some of the configured hardware. Failure to set
this parameter may result in inability for Linux to boot. This
typically happens with the latest CPU models. Because most
hardware provides backward compatibility with older versions,
setting this kernel parameter may enable the system to boot.
However, if no backward compatibility is provided, the system
may panic or fail in other ways even with this parameter set.
* - **Security settings**
- Modify security access settings, such as TLS for OpenStack public
checkpoints, HTTPS for Horizon, SSH Public to access Fuel Slave
nodes.
You can use a self-signed certificate or upload a pre-generated key
and certificate.
- The :guilabel:`Public TLS` configuration includes:
TLS for OpenStack public endpoints
Enables TLS termination on HAProxy for OpenStack services.
HTTPS for Horizon
Secures access to Horizon enabling HTTPS instead of HTTP.
Select source for certificate
Enable :guilabel:`TLS for OpenStack public endpoints`
first to select a certificate. You can generate a private
key with certificate or use the pre-generated ones.
* Self-signed
Generates a private key and certificate to be signed by this key.
* I have my own keypair with certificate
Uses the pre-generated key and certificate. If selected, you need
to specify a certificate and private key data concatenated into
a single file.
DNS hostname for public TLS endpoints
Enable :guilabel:`TLS for OpenStack public endpoints` first
to specify a DNS hostname. Your DNS entries should point
to this name. Self-signed certificates also use this hostname.
The default value is ``public.fuel.local``.
The :guilabel:`SSH security` configuration includes:
Restrict SSH service on network
When enabled, provide at least one working IP address
(the Fuel Master node IP is already added).
Add new addresses instead of replacing the provided
Fuel Master node IP address. When disabled (by default),
the admin, management, and storage networks can only connect
to the SSH service.
Restrict access to
Sets access restriction to the specified range of IP addresses.
* - **Compute settings**
- * Hypervisor
Enables you to modify the previously selected option.
* Nova quotas
Sets tenant quotas on CPU and memory usage.
* Resume guests state on host boot
Controls whether to preserve the state of virtual instances
across reboots.
- Hypervisor
Enables you to modify the previously selected option.
Nova quotas
Sets tenant quotas on CPU and memory usage.
Resume guests state on host boot
Controls whether to preserve the state of virtual instances
across reboots.
* - **Storage settings**
- * Use qcow format for images
If you select this option, ephemeral volumes will be created as a
copy-on-write layer of the base image. If you do not select this
option, ephemeral volumes will be full copies of the base image.
The default setting is to use copy-on-write for ephemeral
volumes.
If you select to use Ceph RBD as a storage back end for ephemeral
volumes, this setting is ignored.
* Storage Backends
Modify storage options you have previously selected in the
deployment wizard. The storage options that you select must match
the roles you assign to a node. For example, if you select
Ceph as a storage back end, you must configure the appropriate
number of nodes with the *Storage - Ceph OSD* role.
* Ceph object replication factor
Determines the minimum number of Ceph OSD nodes that Fuel must
deploy. For a production environment, deploy at least three Ceph
OSD nodes.
- Use qcow format for images
If you select this option, ephemeral volumes will be created as a
copy-on-write layer of the base image. If you do not select this
option, ephemeral volumes will be full copies of the base image.
The default setting is to use copy-on-write for ephemeral
volumes.
If you select to use Ceph RBD as a storage back end for ephemeral
volumes, this setting is ignored.
Storage Backends
Modify storage options you have previously selected in the
deployment wizard. The storage options that you select must match
the roles you assign to a node. For example, if you select
Ceph as a storage back end, you must configure the appropriate
number of nodes with the *Storage - Ceph OSD* role.
Ceph object replication factor
Determines the minimum number of Ceph OSD nodes that Fuel must
deploy. For a production environment, deploy at least three Ceph
OSD nodes.
* - **Logging settings**
- Configure the Puppet and OpenStack debug logging and syslog
settings.
* Common
Typically, you do not need to enable debug logging. Enable debug
logging to analyze the problems in your system.
* Syslog
Fuel deploys an OpenStack environment with the standard Linux
syslog message logging tool. Syslog logs activity of all
OpenStack services. By default, ``rsyslog`` is
configured to use the Fuel Master node as a remote syslog server
that contains all logs generated on all nodes in the OpenStack
environment. If you want to use an external server for
``rsyslog``, specify an IP address and port number of the server
in the :guilabel:`Syslog` field.
Common
Typically, you do not need to enable debug logging. Enable debug
logging to analyze the problems in your system.
Syslog
Fuel deploys an OpenStack environment with the standard Linux
syslog message logging tool. Syslog logs activity of all
OpenStack services. By default, ``rsyslog`` is
configured to use the Fuel Master node as a remote syslog server
that contains all logs generated on all nodes in the OpenStack
environment. If you want to use an external server for
``rsyslog``, specify an IP address and port number of the server
in the :guilabel:`Syslog` field.
* - **OpenStack services**
- Select additional OpenStack services to deploy. Some OpenStack
services may have additional network and storage requirements.

11
userdocs/fuel-user-guide/configure-environment/verify-networks.rst
View File

@@ -1,12 +1,8 @@
.. raw:: pdf
PageBreak
.. _verify-networks-ug:
============================
Verify network configuration
----------------------------
============================
After you configure network settings, verify your network configuration.
Network verification tests connectivity between nodes through configured
@@ -32,4 +28,5 @@ You must resolve all errors before you deploy an OpenStack environment.
.. seealso::
* :ref:`post-deployment-settings`
* :ref:`post-deployment-settings`
* :ref:`ug-network`

34
userdocs/fuel-user-guide/configure-environment/workflows.rst Normal file
View File

@@ -0,0 +1,34 @@
.. _workflow-intro:
Modify the deployment workflow
==============================
A deployment workflow, or deployment graph, is an hierarchy of
deployment tasks with dependencies that Fuel executes to deploy
an OpenStack environment.
A deployment graph enables you to execute complex orchestrated workflows,
such as bugfixes application, reference architecture altering, or upgrades
in a particular order. For example, you can enable specific
network verification tasks for a Fuel plugin or change the default image
delivering protocol (HTTP) for OpenStack nodes provisioning, and so on.
.. warning::
This section describes advanced usage and requires the user to deeply
understand Fuel internals. Do not modify deployment workflows if you are
deploying an OpenStack environment for the first time.
This section includes the following topics:
.. toctree::
:maxdepth: 1
workflows/workflows-overview.rst
workflows/workflows-precedence.rst
workflows/workflows-create.rst
workflows/workflows-data-driven.rst
.. seealso::
- :ref:`workflows_manage`
- :ref:`cli-graphs`
- :ref:`data-driven`

15
userdocs/fuel-user-guide/configure-environment/workflows/workflows-create.rst Normal file
View File

@@ -0,0 +1,15 @@
.. _workflow-create:
Create a custom deployment workflow
===================================
You can modify the release workflow configuration by creating a
cluster or plugin workflow with the required changes.
This section includes the following topics:
.. toctree::
:maxdepth: 1
workflows-create/structure.rst
workflows-create/examples.rst

14
userdocs/fuel-user-guide/configure-environment/workflows/workflows-create/examples.rst Normal file
View File

@@ -0,0 +1,14 @@
Examples
--------
Workflow customization is a powerful mechanism that enables you to
create complex configurations. This section provides examples
of how you can modify a deployment workflow.
.. toctree::
:maxdepth: 1
examples/workflows-add-task.rst
examples/workflows-skip-task.rst
examples/workflows-create-role.rst
examples/workflows-swap-task.rst

39
userdocs/fuel-user-guide/configure-environment/workflows/workflows-create/examples/workflows-add-task.rst Normal file
View File

@@ -0,0 +1,39 @@
.. _workflows-add-task:
Add a task
----------
You can add a task to an existing role.
**To add a task:**
#. Create a ``.yaml`` file.
For example, ``my_tasks.yaml``.
#. Add the task description to the ``my_tasks.yaml`` file.
**Example:**
.. code-block:: console
- id: my_task
type: puppet
groups: [compute]
required_for: [deploy_end]
requires: [netconfig]
parameters:
puppet_manifest: /etc/puppet/modules/my_task.pp
puppet_modules: /etc/puppet/modules
timeout: 3600
#. Log in to the Fuel CLI.
#. Run the following command:
.. code-block:: console
fuel rel --sync-deployment-tasks --dir <path-to-dir-with-the-task.pp>
Fuel syncs the with the internal database.
#. Deploy the OpenStack environment.

121
userdocs/fuel-user-guide/configure-environment/workflows/workflows-create/examples/workflows-create-role.rst Normal file
View File

@@ -0,0 +1,121 @@
.. _workflows-create-task:
Creating a separate role with a task
------------------------------------
You can create a separate role and attach a custom task to that
role. Examples in this section describe installation of a Redis
database server. You can apply similar principles for other
tasks.
.. warning::
We recommend that you add new roles through creating plugins.
**To create a separate role with a task:**
#. Create a ``.yaml`` file with a user-friendly name.
For example, ``redis.yaml``.
#. Open the file for editing and add meta information:
**Example:**
.. code-block:: console
meta:
description: Simple Redis server
name: Controller
name: redis
volumes_roles_mapping:
- allocate_size: min
id: os
#. Create a role using Fuel CLI:
.. code-block:: console
fuel role --rel 1 --create --file <my.yaml>
**Example:**
.. code-block:: console
fuel role --rel 1 --create --file redis.yaml
#. Log in to the Fuel Web UI.
#. In the :guilabel:`Nodes` tab, verify that the required role is created.
#. Attach a task to the newly created role:
#. Log in to Fuel CLI.
#. Install the required Puppet modules.
**Example:**
.. code-block:: console
puppet module install thomasvandoren-redis
#. Write a simple manifest to the required location. For example:
``/etc/puppet/modules/redis/example/simple_redis.pp`` and include redis.
#. Create a deployment task in you ``tasks.yaml``. For example,
``in /etc/puppet/modules/redis/example/redis_tasks.yaml``.
**Example:**
.. code-block:: console
# redis group
- id: redis
type: group
role: [redis]
required_for: [deploy_end]
tasks: [globals, hiera, netconfig, install_redis]
parameters:
strategy:
type: parallel
# Install simple redis server
- id: install_redis
type: puppet
requires: [netconfig]
required_for: [deploy_end]
parameters:
puppet_manifest: /etc/puppet/modules/redis/example/simple_redis.pp
puppet_modules: /etc/puppet/modules
timeout: 180
#. Synchronize deployment tasks:
.. code-block:: console
fuel rel --sync-deployment-tasks --dir <path-to-puppet-manifest>
**Example:**
.. code-block:: console
fuel rel --sync-deployment-tasks --dir /etc/puppet/mitaka-9.0/
#. Configure and create an OpenStack environment with all required
network, storage, and other settings.
#. Provision a node with the created role:
**Example:**
.. code-block:: console
fuel node --node <node_ID> --env <env_ID> --provision
#. Deploy a node with the created role:
.. code-block:: console
fuel node --node <node_ID> --env <env_ID> --deploy
.. seealso::
- `Plugin node roles
<http://docs.openstack.org/developer/fuel-docs/plugindocs/fuel-plugin-sdk-guide/create-plugin/plugin-node-roles.html>`_

55
userdocs/fuel-user-guide/configure-environment/workflows/workflows-create/examples/workflows-skip-task.rst Normal file
View File

@@ -0,0 +1,55 @@
.. _workflows-skip-task:
Skip a deployment task
----------------------
You can skip a deployment task using the type or condition parameter
of the task, or through an API request.
When using API requests, you can specify the list of tasks to skip or
indicate the first and the last task to skip.
**To skip a deployment task:**
#. Select from the following options:
* Specify the ``type`` parameter:
**Example:**
.. code-block:: console
- id: horizon
type: skipped
role: [primary-controller]
requires: [post_deployment_start]
required_for: [post_deployment_end]
* Specify a ``false`` condition:
**Example:**
.. code-block:: console
- id: horizon
type: puppet
role: [primary-controller]
requires: [post_deployment_start]
required_for: [post_deployment_end]
condition: 'true != false'
#. Synchronize deployment tasks:
.. code-block:: console
fuel rel --sync-deployment-tasks --dir <path-to-puppet-manifest>
**Example:**
.. code-block:: console
fuel rel --sync-deployment-tasks --dir /etc/puppet/mitaka-9.0/
.. seealso::
- :ref:`data-driven`

43
userdocs/fuel-user-guide/configure-environment/workflows/workflows-create/examples/workflows-swap-task.rst Normal file
View File

@@ -0,0 +1,43 @@
.. _workloads-replace-task:
Replace a task
--------------
You can replace a task with a custom task in the
``task.yaml`` file by replacing the path to the executable
file.
**To replace a task:**
#. Log in to Fuel CLI:
#. Open the ``task.yaml`` file for editing.
#. Replace the path to the path to the executable file:
.. code-block:: console
- id: netconfig
type: puppet
groups: [primary-controller, controller, cinder, compute, ceph-osd,
zabbix-server, primary-mongo, mongo]
required_for: [deploy_end]
requires: [logging]
parameters:
# old puppet manifest
# puppet_manifest: /etc/puppet/modules/osnailyfacter/netconfig.pp
puppet manifest:
/etc/puppet/modules/osnailyfacter/custom_network_configuration.pp
puppet_modules: /etc/puppet/modules
timeout: 3600
#. Synchronize deployment tasks:
.. code-block:: console
fuel rel --sync-deployment-tasks --dir <path-to-puppet-manifest>
**Example:**
.. code-block:: console
fuel rel --sync-deployment-tasks --dir /etc/puppet/mitaka-9.0/

218
userdocs/fuel-user-guide/configure-environment/workflows/workflows-create/structure.rst Normal file
View File

@@ -0,0 +1,218 @@
.. _workflow-create-structure:
Workflow task structure
-----------------------
You can group the tasks defined in the deployment workflow
file using the types described in this section.
The following table describes the workflow task structure:
.. list-table:: **Workflow task structure**
:widths: 10 10 10
:header-rows: 1
* - Parameter
- Description
- Example
* - ``id``
- Name of the deployment task.
-
* - ``version``
- Version of the workflow execution engine.
-
* - ``type``
- A type of task that Fuel executes. You can specify the
following types of tasks:
-
* - ``stage``
- Divides a deployment workflow on phases. In the default
release workflow Fuel has the following stages:
- ``pre_deployment_start``
- ``pre_deployment_end``
- ``deploy_start``
- ``deploy_end``
- ``post_deployment_start``
- ``post_deployment_end``
However, you can create any stages as required or do
not use them at all.
- ::
id: deploy_end
type: stage
requires: [deploy_start]
* - ``groups``
- Describes node roles. By default, Fuel executes all tasks
simultaneously. Hovewer, the order of tasks execution can be defined
in the cross-depends and cross-depended-by fields of tasks.
* ``one_by_one`` - deploy all nodes in this group one after another.
- ::
- id: controller
type: group
role: [controller]
requires: [primary-controller]
required_for: [deploy_end]
* - ``skipped``
- Fuel does not execute this task, but preserves all dependencies specified
in the tasks. For example, if you use a plugin that requires some to be
skipped, you can create a ``skipped`` task in the plugin workflow file.
- ::
- id: netconfig
type: skipped
groups: [primary-controller, controller, cinder, compute, ceph-osd,
zabbix-server, primary-mongo, mongo]
required_for: [deploy_end]
requires: [logging]
parameters:
puppet_manifest: /etc/puppet/modules/osnailyfacter/netconfig.pp
puppet_modules: /etc/puppet/modules
timeout: 3600
* - ``puppet``
- Deploys Puppet manifests.
- ::
- id: netconfig
type: puppet
groups: [primary-controller, controller, cinder, compute, ceph-osd,
zabbix-server, primary-mongo, mongo]
required_for: [deploy_end]
requires: [logging]
parameters:
puppet_manifest:
/etc/puppet/modules/osnailyfacter/other_path/netconfig.pp
puppet_modules: /etc/puppet/modules
timeout: 3600
* - ``shell``
- Executes shell scripts.
- ::
- id: enable_quorum
type: shell
role: [primary-controller]
requires: [post_deployment_start]
required_for: [post_deployment_end]
parameters:
cmd: ruby
/etc/puppet/modules/osnailyfacter/modular/astute/enable_quorum.rb
timeout: 180
* - ``upload_file``
- Uploads values specified in ``data`` in the ``parameters`` section.
- ::
- id: upload_data_to_file
type: upload_file
role: '*'
requires: [pre_deployment_start]
parameters:
path: /etc/file_name
data: 'arbitrary info'
* - ``sync``
- Distributes files from the ``src`` direcory on the Fuel Master node
to the ``dst`` directory on the Fuel Slave nodes that match the
specified roles.
- ::
- id: rsync_core_puppet
type: sync
role: '*'
required_for: [pre_deployment_end]
requires: [upload_core_repos]
parameters:
src: rsync://<FUEL_MASTER_IP>:/puppet/
dst: /etc/puppet
timeout:
* - ``copy_files``
- Reads data from ``src`` and saves it in the file specified in the
``dst`` argument. Permissions can be specified for a group of files.
- ::
- id: copy_keys
type: copy_files
role: '*'
required_for: [pre_deployment_end]
requires: [generate_keys]
parameters:
files:
src: /var/lib/fuel/keys/{CLUSTER_ID}/neutron/neutron.pub
dst: /var/lib/astute/neutron/neutron.pub
permissions: '0600'
dir_permissions: '0700'
* - ``role``
- Node roles on which the task is executed. To select all roles assigned
to the node, you can use a wildcard '*'.
- ::
role: [primary-controller]
* - ``requires``
- Requirements for a specific task or stage on the same node.
- ::
requires: [generate_keys]
* - ``required_for``
- Specifies which tasks and stages depend on this task.
- ::
required_for: [pre_deployment_end]
* - ``reexecute_on``
- Re-run the task after completion.
- ::
reexecute_on: [deploy_changes]
* - ``cross-depended-by``
- Specifies which tasks and stages on other nodes are dependent by this
task. You can specify a value in a form of a regular expression.
For example, use ``name:`` entries. Do not use lists
not use lists.
.. warning:: The ``cross-depends`` and ``requires`` fields have
different syntax!
- ::
cross-depended-by:
- name: neutron-keystone
* - ``cross-depends``
- Reverse to ``cross-depended-by``. You can specify the value in a form
of a regular expression. Do not use lists.
- ::
cross-depends:
- name: neutron-keystone
role: primary-controller
- name: openstack-haproxy
* - ``condition``
- Describes a condition required to execute this task.
For more information, see: :ref:`data-driven`.
- ::
condition: yaql_exp: {yaql expression}
parameters:
data: yaql_exp: {yaql expression}
* - ``parameters``
- Task execution parameters. Differ for each task.
- ::
parameters:
files:
- src: /var/lib/fuel/keys/{CLUSTER_ID}/neutron/neutron.pub
dst: /var/lib/astute/neutron/neutron.pub
permissions: '0600'
dir_permissions: '0700'

1
userdocs/fuel-user-guide/maintain-environment/data-driven.rst → userdocs/fuel-user-guide/configure-environment/workflows/workflows-data-driven.rst
View File

@@ -1,6 +1,7 @@
.. _data-driven:
=====================
Run data-driven tasks
=====================

37
userdocs/fuel-user-guide/configure-environment/workflows/workflows-overview.rst Normal file
View File

@@ -0,0 +1,37 @@
.. _workflow-overview:
Overview of the deployment workflows
------------------------------------
You can modify the following OpenStack environment deployment stages
using custom deployment workflows:
* **Deletion** - if you deploy a brand new environment, Fuel
skips this step. If you make changes to the existing environment, Fuel
deletes nodes that were marked for deletion.
* **Network verification** - Fuel verifies network configuration
of the OpenStack environment.
* **Provisioning** - Fuel provisions the OpenStack nodes.
* **Deployment** - Fuel deploys the OpenStack environment.
An OpenStack environment has the following level of deployment workflows:
* ``release`` - describes the default OpenStack environment workflows.
We do not recommend to make any changes in the release workflow. Apply
all changes to the release workflow by creating and modifying the plugin
and cluster workflows.
* ``plugin`` - describes plugin deployment workflow. During the deployment,
Fuel merges the configuration described in the plugin workflows with
the release workflow and applies a unified deployment graph. Typically,
plugin's source code includes the descriptions of deployment workflow in
``deployment_tasks.yaml``. By default, Fuel includes an empty plugin
workflow. If you want to make changes in an OpenStack environment,
creating a plugin is the preferred way.
* ``cluster`` - describes the changes that will be applied to this OpenStack
environment. Use this option only if creating a plugin is not possible.
In all other cases, create a plugin.

47
userdocs/fuel-user-guide/configure-environment/workflows/workflows-precedence.rst Normal file
View File

@@ -0,0 +1,47 @@
.. _workflows_precedence:
========================================
Deployment workflows order of precedence
========================================
Each OpenStack environment has the following classes of deployment workflows
listed in a descending order of importance:
* Environment specific workflows (highest priority)
* Graphs introduced by plugins
* Release specific workflows (lowest priority)
A custom deployment workflow may be of any particular type and is stored
in the database with this type. The default deployment workflows belong to
the ``default`` type.
Each deployment run executes the deployment of a particular type.
Fuel fetches the workflows of each of the available classes for
the corresponding type of deployment and merges the workflows by merging
all tasks by tasks IDs where tasks of a higher priority override tasks of
a lower priority.
The merge order of plugins workflows is not deterministic as it is supposed that
plugins workflows have no tasks intersections by task IDs.
**Examples of workflow execution:**
* Fuel applies deployment workflows for default deployments in the following
order:
* Release default workflows from the ``tasks.yaml`` file from fuel-library
* Plugins default workflows located in ``deployment_tasks.yaml`` in
plugins` source code
* Environment default workflows that are empty by default
* Fuel applies deployment workflows for custom deployments in the following
order:
* Release custom workflows from the ``tasks.yaml`` file from fuel-library
or delivered by a maintenance update
* Plugins custom workflows specified by plugin developers in plugins` source
code
* Environment custom workflows that include environment specific tasks
specified by the user

6
userdocs/fuel-user-guide/deploy-environment/deploy-changes.rst
View File

@@ -32,4 +32,8 @@ minutes to an hour.
#. Unfold :guilabel:`Choose nodes for deployment` and
select nodes.
#. Click :guilabel:`Deploy Nodes`.
#. Click :guilabel:`Deploy Nodes`.
.. seealso::
* :ref:`view_workflows`

2
userdocs/fuel-user-guide/file-ref/settings-yaml.rst
View File

@@ -26,7 +26,7 @@ Usage
fuel --env 1 settings default
where ``--env 1`` that to the specific environment
where ``--env 1`` points to the specific environment
(id=1 in this example).

13
userdocs/fuel-user-guide/install-additional-components.rst
View File

@@ -7,13 +7,12 @@
Install additional components
=============================
If you want to install additional components, such as the OpenStack
Application Catalog service (Murano), the Telemetry service (Ceilometer), the
Bare Metal service (Ironic), or the Hadoop cluster (Sahara), you must
select a corresponding checkbox in the deployment wizard. However,
some components require additional configuration before
installation. This section describes the installation process for
the OpenStack programs that require additional attention.
If you want to install additional components, such as the OpenStack Telemetry
service (Ceilometer), the Bare Metal service (Ironic), or the Hadoop cluster
(Sahara), you must select a corresponding checkbox in the deployment wizard.
However, some components require additional configuration before installation.
This section describes the installation process for the OpenStack programs
that require additional attention.
Follow the steps described in the corresponding sub-sections of this section.

15
userdocs/fuel-user-guide/maintain-environment.rst
View File

@@ -1,5 +1,6 @@
.. _maintain-environment:
===================================
Maintain your OpenStack environment
===================================
@@ -14,11 +15,15 @@ This section includes the following topics:
.. toctree::
:maxdepth: 1
maintain-environment/backup-fuel
maintain-environment/restore-fuel
maintain-environment/remove-node.rst
maintain-environment/redeploy-node.rst
maintain-environment/access-shell.rst
maintain-environment/rollback-ug.rst
maintain-environment/reinstall-node.rst
maintain-environment/reinstall-virtual-role.rst
maintain-environment/use-shotgun.rst
maintain-environment/custom-graph.rst
maintain-environment/data-driven.rst
maintain-environment/deployment-history.rst
maintain-environment/deployment-information.rst
maintain-environment/create-snapshot.rst
maintain-environment/workflows-manage.rst
maintain-environment/shutdown-env.rst
maintain-environment/start-env.rst

93
userdocs/fuel-user-guide/maintain-environment/access-shell.rst Normal file
View File

@@ -0,0 +1,93 @@
.. _access_shell:
=====================
Access shell on nodes
=====================
While maintaining your OpenStack environment or performing advanced
configuration tasks, you may need to access the Fuel Master node and
Fuel slave nodes at the shell level. Operating systems on all nodes
run the **bash** shell supporting standard Unix system commands.
Each node's system has its own console that you can use directly, but
standard practice is to use SSH to access consoles of Fuel nodes.
**To access the shell on nodes through SSH:**
#. Generate a public SSH key by typing on your client:
.. code-block:: console
ssh-keygen -t rsa
#. Log in to the Fuel web UI.
#. Go to :guilabel:`Settings -> General -> Operating System Access`.
#. Paste the public key to the :guilabel:`Authorized SSH keys` field.
Fuel uploads public keys to each Fuel slave node it deploys.
However, you cannot upload the keys to the Fuel Master node
and Fuel slave nodes that have already been deployed through the Fuel
web UI. Proceed with the steps below to upload public keys to
the Fuel Master node and deployed Fuel slave nodes.
#. To upload the SSH key to the Fuel Master node, type on your client:
.. code-block:: console
ssh-copy-id -i .ssh/id_rsa.pub root@<FUEL_MASTER_IP>
<FUEL_MASTER_IP>
The IP address of the Fuel Master node.
Alternatively, add the required public key stored in
the ``.ssh/id_rsa.pub`` file to the ``/root/.ssh/authorized_keys``
directory on the Fuel Master node.
#. SSH to the Fuel Master node:
.. code-block:: console
ssh root@<FUEL_MASTER_IP>
#. Type :command:`fuel nodes` or :command:`fuel node list` to get the IP
addresses of all Fuel slave nodes.
**Example of system response:**
.. code-block:: console
id | status | name | cluster | ip | mac | roles | pending_roles | online
---|--------|------------------|---------|------------|-------------------|------------|---------------|-------
5 | ready | Untitled (4d:4d) | 2 | 10.110.0.3 | b2:8b:55:17:ae:40 | controller | | True
8 | ready | Untitled (3a:7f) | 2 | 10.110.0.6 | 92:93:99:70:14:4c | compute | | True
6 | ready | Untitled (34:84) | 2 | 10.110.0.4 | f2:b3:1a:74:da:41 | cinder | | True
7 | ready | Untitled (f0:9b) | 2 | 10.110.0.5 | 56:09:fe:c6:06:40 | compute | | True
#. To upload the SSH key to a deployed Fuel slave node, type:
.. code-block:: console
ssh-copy-id -i .ssh/id_rsa.pub root@<FUEL_SLAVE_IP>
Alternatively, add the required public key stored in
the ``.ssh/id_rsa.pub`` file to the ``/root/.ssh/authorized_keys``
directory on the required Fuel slave node.
#. SSH to the Fuel slave node using either its IP address or ID:
* To :command:`ssh` using an IP address, type, for example:
.. code-block:: console
ssh 10.110.0.4
* To :command:`ssh` using an ID shown in the first column of
the :command:`fuel nodes` command output, type, for example:
.. code-block:: console
ssh node-6
Now, you can use :command:`ssh` to access the console of the Fuel Master node
and consoles of the Fuel slave nodes from the Fuel Master node.
Besides, you can use :command:`scp` and :command:`sftp` commands to securely
copy files to the nodes.

55
userdocs/fuel-user-guide/maintain-environment/backup-fuel.rst Normal file
View File

@@ -0,0 +1,55 @@
.. _back-up-fuel:
============================
Back up the Fuel Master node
============================
Fuel enables you to back up the Fuel Master node. You may need to perform
the backup of the Fuel Master node as a part of the upgrade procedure or
use the backup archives to restore the Fuel Master node in case of a hardware
failure.
**To back up the Fuel Master node:**
#. Log in to the Fuel Master node CLI.
#. Download and install the ``fuel-octane`` package:
.. code-block:: console
$ yum install fuel-octane
#. Back up the configuration state of the Fuel Master node:
.. code-block:: console
$ octane fuel-backup --to <base-archive-name>.tar.gz
#. Back up package repositories and other binary artifacts from the Fuel
Master node:
.. code-block:: console
$ octane fuel-repo-backup --full --to <repo-archive-name>.tar.gz
**Example:**
.. code-block:: console
$ octane fuel-repo-backup --full --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 do not 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.
Now, you can upgrade or restore the Fuel Master node from the backup files.
.. seealso::
* :ref:`restore-fuel`
* :ref:`upgrade_liberty`

78
userdocs/fuel-user-guide/maintain-environment/create-snapshot.rst Normal file
View File

@@ -0,0 +1,78 @@
.. _create-snapshot:
============================
Create a diagnostic snapshot
============================
Fuel enables you to generate a diagnostic snapshot of your OpenStack
environment to simplify troubleshooting. The diagnostic snapshot feature
is available right after the Fuel Master node installs.
Fuel uses timmy, a diagnostic utility for OpenStack environments, to generate
diagnostic snapshots through the Fuel web UI or CLI.
**To create a diagnostic snapshot using the Fuel web UI:**
#. Log in to the Fuel web UI.
#. Navigate to :menuselection:`Support > Download Diagnostic Snapshot`.
#. Click :guilabel:`Generate Diagnostic Snapshot`.
By default, Fuel generates a diagnostic snapshot of all OpenStack nodes
with log files updated in the last 3 days creating a ``.tar`` tarball
with archives inside that becomes available for downloading once the generation
of a snapshot completes successfully.
**To create a diagnostic snapshot using the Fuel Master CLI:**
#. Log in to the Fuel Master CLI.
#. Use the :command:`timmy` command to create a snapshot:
.. code-block:: console
timmy
The :command:`timmy` command initiates the snapshot creation of all
OpenStack nodes without log collection and according to default
configuration.
You can specify additional options for the :command:`timmy` command.
**Examples:**
* Create a diagnostic snapshot according to default configuration but
with log collection for a definite period of time in days:
.. code-block:: console
timmy --logs --days <NUM>
.. note:: If not specified, timmy collects log files updated in the last
30 days.
* Run timmy on a particular OpenStack node:
.. code-block:: console
timmy --env <ENV_ID> --id <NODE_ID>
* Run timmy on a particular node role:
.. code-block:: console
timmy --role <ROLE_NAME>
* Specify a custom filename for the snapshot archive:
.. code-block:: console
timmy --dest-file <FILE_NAME>
If log files are collected, they will be placed in the specified folder
but as separate archives.
.. note:: By default, timmy creates a ``general.tar.gz`` snapshot
and stores it in ``/tmp/timmy/archives``.
.. seealso::
* `Timmy documentation <http://timmy.readthedocs.io/en/latest/index.html>`__

111
userdocs/fuel-user-guide/maintain-environment/custom-graph.rst
View File

@@ -1,111 +0,0 @@
.. _custom-graph:
Run a custom graph
==================
You can execute a custom deployment graph and merge it with existing deployment
graphs of the upstream master release.
This allows you to implement complex orchestrated workflows, such as
bugfixes application, reference architecture altering, or even upgrades.
Each cluster has three classes of deployment graphs with the following
hierarchy listed in a descending order of importance:
* Cluster-specific graph (most important).
* Graphs introduced by plugins -- These are the graphs of the enabled
plugins merged by the task ID.
* Release-default graph (least important).
The custom graph may be of any particular type and is stored in the database
with this type. The default deployment graphs have the type ``default``.
Each deployment run executes the deployment of a particular type
(``default`` by default). Fuel fetches the graphs of each of the three classes
for the corresponding type of deployment and merges the graphs by merging all
tasks by task IDs where high-level tasks override the lower ones.
An example in the order of the graphs overriding:
**Default deployment:**
#. Release the default graph as derived from the tasks.yaml file of
fuel-library.
#. Plugins default graphs, which are ``deployment_tasks.yaml`` from plugins
manifests.
#. Cluster default grap, which is empty by default, with cluster-specific
tasks specified by the user
The plugins graph merge order is not deterministic and it is supposed that
plugins graphs have no tasks intersections by task ID.
**Custom-type graph:**
#. Release custom-type graph, which is empty at this stage but can be derived
from the tasks.yaml file of fuel-library or be delivered by a maintenance
update.
#. Plugins custom-type graphs can be specified by plugin developers.
#. Cluster default grap, which is empty by default, with cluster-specific
tasks specified by the user
To list a cluster-specific table with graphs, their relations, names, and
types:
The graph ``name`` is an arbitrary parameter that defines additional
information about the graph. It has no impact on the business logic.
#. Log in to the Fuel master node.
#. Run the following command:
.. code-block:: console
fuel2 graph list --env env_id
where ``env_id`` is the ID of the environment.
To upload a graph:
#. Log in to the Fuel master node.
#. Run the following command:
.. code-block:: console
fuel2 graph upload --env env_id [--type graph_type] --file tasks.yaml
fuel2 graph upload --release release_id [--type graph_type] --file tasks.yaml
fuel2 graph upload --plugin plugin_id [--type graph_type] --file tasks.yaml
where ``--type`` is an optional parameter. The ``default`` graph type with
confirmation should be used if no type is defined.
Thw graphs downloaded with the keys ``--all`` and ``--plugins`` are the
result of other graphs merge performed by Nailgun and are not supposed to be
edited and uploaded back.
In most cases because they will completely override further changes made in
source graphs.
To download a graph:
#. Log in to the Fuel master node.
#. Run the following command:
.. code-block:: console
fuel2 graph download --env env_id --all [--type graph_type] [--file cluster_graph.yaml]
fuel2 graph download --env env_id --cluster [--type graph_type] [--file cluster_graph.yaml]
fuel2 graph download --env env_id --plugins [--type graph_type] [--file plugins_graph.yaml]
fuel2 graph download --env env_id --release [--type graph_type] [--file release_graph.yaml]
where ``--type`` is an optional parameter. The command downloads the
``default``if no type is defined.
To execute a graph:
#. Log in to the Fuel master node.
#. Run the following command:
.. code-block:: console
fuel2 graph execute --env env_id [--type graph_type] [--node node_ids]
Graph execution is available only for the environment.

35
userdocs/fuel-user-guide/maintain-environment/deployment-history.rst
View File

@@ -1,35 +0,0 @@
.. _deployment-history:
Deployment task history
=======================
Fuel stores in its database the information about all deployment
tasks associated with each deployment.
To get the information on a deployment task:
#. Log in to the Fuel master node.
#. Find the ID of the deployment task:
.. code-block:: console
fuel task
fuel2 task list
#. Get the information on the deployment task:
.. code-block:: console
fuel deployment-tasks --task-id <task-id> --statuses ready, pending --nodes 1,2
fuel2 task history show <task-id> --nodes 3 --statuses error skipped
where <task-id> is the ID of the deployment task.
.. warning:: The commands ``fuel task`` and ``fuel2 task list`` show
the Nailgun tasks; for example, provisioning, deployment,
verify networks, and so on.
The commands ``fuel deployment-tasks`` and
``fuel2 task history show`` show the deployment tasks
running on nodes; for example, database, upload_configuration,
hiera, and so on.

31
userdocs/fuel-user-guide/maintain-environment/deployment-information.rst
View File

@@ -1,31 +0,0 @@
.. _deployment-information:
Download deployment information
===============================
Fuel stores detailed information about deployments in its database.
You can download cluster settings, network configuration, and serialized
cluster data, such as ``astute.yaml`` for all nodes used for a specific
deployment.
**To download the deployment information:**
#. Log in to the Fuel Master node.
#. Get the ID of the deployment task:
.. code-block:: console
fuel task
fuel2 task list
#. Download the deployment information:
.. code-block:: console
fuel2 task deployment-info download <task-id> --file deployment-info.yaml
fuel2 task settings download <task-id> --file settings.yaml
fuel2 task network-configuration download <task-id> --file networks.yaml
The ``<task-id>`` value is the ID of the deployment task.

3
userdocs/fuel-user-guide/maintain-environment/preserve-partition.rst
View File

@@ -1,7 +1,8 @@
.. _preserve-partition:
====================
Preserve a partition
~~~~~~~~~~~~~~~~~~~~
====================
This section is a part of the :ref:`Rollback a node <rollback-ug>` procedure.
With partition preservation you can keep any type of data that meets the

38
userdocs/fuel-user-guide/maintain-environment/redeploy-node.rst Normal file
View File

@@ -0,0 +1,38 @@
.. _redeploy-node:
===============
Redeploy a node
===============
Redeploying a node refers to the process of changing the roles that are
assigned to a node. For example, you want to redeploy some compute and storage
nodes to be MongoDB nodes.
**To redeploy a node:**
#. Prepare your environment:
#. Live migrate instances from the compute nodes. For more information,
see `Configure migrations <http://docs.openstack.org/admin-guide-cloud/compute-configuring-migrations.html>`_.
#. Back up or copy information from the Operating System nodes being
redeployed.
#. Log in to the Fuel web UI.
#. In the :guilabel:`Nodes` tab, select the node(s) that you want to remove
and click :guilabel:`Delete`.
The deployed node will be marked as :guilabel:`PENDING DELETION`.
#. In the :guilabel:`Dashboard` tab, click :guilabel:`Deploy Changes`.
#. Wait for the node to become available in the list of :guilabel:`Discovered`
nodes in the :guilabel:`Nodes` tab.
#. Assign a new role to the node being redeployed.
#. Adjust the settings of your environment as required.
#. In the :guilabel:`Dashboard` tab, click :guilabel:`Deploy Changes`.
#. Wait for the environment to be redeployed.
.. caution:: After redeploying an Operating System node, you will have to
manually apply any configuration changes you made and reinstall the software
that was running on the node or restore the system from the backup you made
before redeploying the node.

1
userdocs/fuel-user-guide/maintain-environment/reinstall-node.rst
View File

@@ -1,5 +1,6 @@
.. _reinstall-node:
================
Reinstall a node
================

3
userdocs/fuel-user-guide/maintain-environment/reinstall-virtual-role.rst
View File

@@ -1,7 +1,8 @@
.. _reinstall-virtual-role:
========================
Reinstall a virtual role
------------------------
========================
If you have the Reduced Footprint feature enabled, you may need to reinstall
the virtual role.

28
userdocs/fuel-user-guide/maintain-environment/remove-node.rst Normal file
View File

@@ -0,0 +1,28 @@
.. _remove-node:
=============
Remove a node
=============
You may need to remove a node from your environment to replace
hardware, repair an error, complete maintenance operations, and so on.
**To remove a node:**
#. Log in to the Fuel web UI.
#. In the :guilabel:`Nodes` tab, select the node that you want to remove and
click :guilabel:`Delete`.
The deployed node will be marked as :guilabel:`PENDING DELETION` and will
be removed from the environment after redeployment.
#. Adjust the settings of your environment as required.
#. In the :guilabel:`Dashboard` tab, click :guilabel:`Deploy Changes`.
Puppet removes the node from the configuration files and
re-triggers corresponding services.
.. seealso::
- `Node management commands <http://docs.openstack.org/developer/fuel-docs/userdocs/fuel-user-guide/cli/cli_nodes.html>`_
- :ref:`add-nodes-ug`
- :ref:`redeploy-node`

61
userdocs/fuel-user-guide/maintain-environment/restore-fuel.rst Normal file
View File

@@ -0,0 +1,61 @@
.. _restore-fuel:
============================
Restore the Fuel Master node
============================
You can restore the Fuel Master node from the backup archives. You may
require to restore in case of a hardware failure or other system
malfunction, or as a part of the upgrade of the Fuel Master node
procedure.
**To restore the Fuel Master node:**
#. Reinstall the Fuel Master node using the respective version of the ISO
image as described in :ref:`install_intro`.
.. warning:: The new Fuel Master node must have the same IP address
and the same administrator password as the original Fuel Master node.
Otherwise, you cannot restore the configuration from the backup files.
#. Copy the corresponding backup archives to the Fuel Master node.
For example, in the ``/tmp`` directory.
#. Log in to the new Fuel Master node.
#. Download and install the ``fuel-octane`` package:
.. code-block:: console
$ yum install fuel-octane
#. Restore the configuration state of the Fuel Master node from the backup
archive:
.. code-block:: console
$ octane fuel-restore --from <base-archive-name>.tar.gz --admin-password <admin-password>
The ``--admin-password`` option is the password that is stored
in a backup file, and is not the current Administrator password.
#. Restore package repositories, base images, and other data from the archive:
.. code-block:: console
$ octane fuel-repo-restore --from <repo-archive-name>.tar.gz \
--admin-password <admin-password>
.. warning:: The Fuel Master node must have at least 2 GB of RAM
to decompress the archive.
#. In case of multiple cluster networks, forward DHCP requests to
the Fuel Master node using one of the following methods:
* Configure switches to relay DHCP
* Use a relay client, such as ``dhcp-helper``
.. seealso::
* :ref:`back-up-fuel`
* :ref:`upgrade_liberty`

4
userdocs/fuel-user-guide/maintain-environment/rollback-compute-node.rst
View File

@@ -1,7 +1,8 @@
.. _rollback-compute-node:
=======================
Rollback a compute node
-----------------------
=======================
You can rollback a compute node to its original state, for example, the state
before it failed.
@@ -57,4 +58,5 @@ before it failed.
.. seealso::
* :ref:`access_shell`
* `Planned Maintenance <http://docs.openstack.org/ops-guide/ops_maintenance_compute.html#planned-maintenance>`_

1
userdocs/fuel-user-guide/maintain-environment/rollback-ug.rst
View File

@@ -1,5 +1,6 @@
.. _rollback-ug:
===============
Rollback a node
===============

117
userdocs/fuel-user-guide/maintain-environment/shutdown-env.rst Normal file
View File

@@ -0,0 +1,117 @@
.. _shutdown-env:
==================================
Shut down an OpenStack environment
==================================
This section provides the recommended process for shutting down an entire
OpenStack environment. You may need to shut down an OpenStack environment
if you want to perform maintenance or recovery procedures. The shutdown
process involves stopping all OpenStack virtual machines, the Fuel Master
node, compute, controller and other nodes in a determinate order. Adhering
to the procedure ensures that the shutdown process is performed gracefully
and mitigates the risks of failure during a subsequent start of
the environment.
**To shut down an entire OpenStack environment:**
#. Shut down the OpenStack virtual machines gracefully through either
Horizon or CLI.
Verify if any virtual machines in your OpenStack environment require
customized shutdown procedure or special shutdown sequence between
several virtual machines. Shut down or suspend these instances gracefully.
#. Shut down compute nodes.
Log in to each compute node as administrator and type:
.. code-block:: console
poweroff
.. note:: All compute nodes may be shut down at the same time.
.. warning::
If a node combines more than one role, you may need to perform
additional steps, such as setting the ``noout`` flag for Ceph OSD nodes,
before you can shut down the node.
#. Shut down Ceph OSD nodes:
#. Set the ``noout`` flag to prevent the rebalance procedure launch
that can be triggered by a delay between Ceph nodes powering off:
#. Log in to any controller node or any Ceph OSD node and type:
.. code-block:: console
ceph osd set noout
#. Verify the ``noout`` flag is set:
.. code-block:: console
ceph -s
The output of the command above should show the ``noout`` flag
set into the health status.
#. On each ceph osd node, type:
.. code-block:: console
poweroff
#. Shut down controller nodes by powering them off sequentially.
An estimated duration of a single controller node shutdown is 30 minutes.
However, it may take more time depending on configuration.
Most of the time the system shows the ``unload corosync services`` message.
Assuming your environment contains 3 controller nodes, shut them down
as follows:
#. Put the pacemaker cluster in maintenance mode:
.. code-block:: console
pcs property set maintenance-mode=true
#. Log in to the Controller-03 node as Administrator and type:
.. code-block:: console
poweroff
Wait until the node accomplishes the poweroff procedure and
some extra minutes to enable Pacemaker/Corosync to redistribute
services between the remained controller nodes.
#. Log in to the Controller-02 node as Administrator and type:
.. code-block:: console
poweroff
Wait until the node accomplishes the poweroff procedure and
some extra minutes to enable Pacemaker/Corosync to stop all services
on a single remained controller node due to no quorum.
#. Log in to the Controller-01 node as Administrator and type:
.. code-block:: console
poweroff
#. Shut down the Fuel Master node. Log in to the Fuel Master node CLI and
type:
.. code-block:: console
poweroff
#. Shut down any remaining nodes in your environment.
#. If required, shut down the networking infrastructure.
#. To start an environment, proceed to :ref:`start-env`.

92
userdocs/fuel-user-guide/maintain-environment/start-env.rst Normal file
View File

@@ -0,0 +1,92 @@
.. _start-env:
==============================
Start an OpenStack environment
==============================
To resume an OpenStack environment after it has been shut down, you need
to bring the environment back to operation. This section provides instructions
on how to start an entire OpenStack environment.
**To start an OpenStack environment:**
#. Verify that hardware is up and running.
#. Power on the Fuel Master node.
#. Start controller nodes.
Assuming your environment contains 3 controller nodes, start them
as follows:
.. note::
The first controller node to start is the controller node that
was shut down last.
#. Start the Controller-01 node.
Wait until the node accomplishes the boot process and some extra minutes
for Pacemaker/Corosync to complete the start up and to shut down
the required services due to no quorum.
#. Start the Controller-02 node.
Wait until the node accomplishes the boot process and some extra minutes
for Pacemaker/Corosync to complete the start up and to redistribute
the OpenStack services between the nodes.
#. Start the Controller-03 node.
Wait until the node accomplishes the boot process and some extra minutes
for Pacemaker/Corosync to complete the start up and to redistribute
the OpenStack services between the nodes.
#. Remove the maintenance mode from the Pacemaker resources:
.. code-block:: console
pcs property set maintenance-mode=false
#. Verify the Galera service.
.. warning::
If your configuration includes a MySQL database of a huge size,
Galera may stay in the syncing state for several hours until it
verifies both MySQL replicas between the available controllers.
Do not interrupt syncing, wait until Galera finishes the process.
#. Start Ceph OSD nodes.
You can start all Ceph OSD nodes at the same time. Ceph starts
Ceph OSD services one by one, depending on the current load to Ceph
monitors.
#. Verify that all Ceph OSD nodes are up and running by logging in to
any controller node and typing:
.. code-block:: console
ceph osd tree
If some Ceph OSD nodes are not up and running, check it manually.
#. Remove the ``noout`` flag:
#. Log in to any controller or any Ceph node and type:
.. code-block:: console
ceph osd unset noout
#. Verify the flag is set:
.. code-block:: console
ceph -s
The output of the command above should NOT show the ``noout`` flag
set into the health status.
#. Start compute nodes.
#. Verify the OpenStack services.
#. Start virtual machines through either Horizon or CLI.

51
userdocs/fuel-user-guide/maintain-environment/use-shotgun.rst
View File

@@ -1,51 +0,0 @@
.. _shotgun-ug:
Create diagnostic snapshot using shotgun
========================================
Shotgun is a tool that you can use to generate diagnostic snapshots
for Fuel. Although, Fuel API for diagnostic snapshots provides similar
functionality, you may prefer to use Shotgun due to the following limitations
of Fuel API:
* When the size of log files is too big, Fuel drops a timeout exceptions.
* When you use Fuel API, you may run out of space in the */var/* partition.
Therefore, use Shotgun from the Fuel Master node directly and fetch the
default configuration from the Fuel Client.
Shotgun stores temporary snapshots in ``/var/www/nailgun/dump/fuel-snapshot``.
A symlink to the last compressed snapshot is located in
``/var/www/nailgun/dump/last``.
With Shotgun you can use standard commands, such as :command:`dir`,
:command:`command`, and :command:`file`:
.. code-block:: ini
- command: brctl show
to_file: brctl_show.txt
type: command
- path: /etc/sysconfig/network-scripts
type: dir
**To use Shotgun:**
#. Install Shotgun on the Fuel Master node:
.. code-block:: console
yum install -y shotgun
#. Fetch the default configuration:
.. code-block:: console
fuel snapshot --conf > dump_conf.yaml
#. Provide the configuration to Shotgun and execute it:
.. code-block:: console
shotgun -c dump_conf.yaml

30
userdocs/fuel-user-guide/maintain-environment/workflows-manage.rst Normal file
View File

@@ -0,0 +1,30 @@
.. _workflows_manage:
================
Manage workflows
================
Fuel enables you to manage the deployment workflows through both the Fuel web
UI and CLI. You can view, upload, download, and execute default workflows
as well as the custom ones. Execution of the custom deployment workflows
and merging them with the default deployment workflows allows for the
implementation of complex orchestrated workflows, such as bug fixes application,
reference architecture alteration, and upgrades.
This section includes the following topics:
.. toctree::
:maxdepth: 2
workflows-manage/view-workflows.rst
workflows-manage/upload-workflows.rst
workflows-manage/download-workflows.rst
workflows-manage/run-workflows.rst
workflows-manage/view-history.rst
workflows-manage/download-deployment-info.rst
.. seealso::
* :ref:`workflow-intro`
* :ref:`cli-graphs`
* :ref:`data-driven`

30
userdocs/fuel-user-guide/maintain-environment/workflows-manage/download-deployment-info.rst Normal file
View File

@@ -0,0 +1,30 @@
.. _deployment-information:
===============================
Download deployment information
===============================
Fuel stores detailed information about deployments in its database.
You can download environment settings, network configuration, and serialized
environment data, such as ``astute.yaml`` for all nodes used for a specific
deployment.
**To download the deployment information:**
#. Log in to the Fuel Master node CLI.
#. Obtain the ID of the deployment task using one of the following commands:
.. code-block:: console
fuel task
fuel2 task list
#. Download the deployment information:
.. code-block:: console
fuel2 task deployment-info download <TASK_ID> --file deployment-info.yaml
fuel2 task settings download <TASK_ID> --file settings.yaml
fuel2 task network-configuration download <TASK_ID> --file networks.yaml
where ``<TASK_ID>`` is the ID of the deployment task.

32
userdocs/fuel-user-guide/maintain-environment/workflows-manage/download-workflows.rst Normal file
View File

@@ -0,0 +1,32 @@
.. _download_workflows:
==============================
Download a deployment workflow
==============================
Fuel enables you to download deployment workflows using the Fuel web UI or
Fuel CLI.
**To download a deployment workflow using the Fuel web UI:**
#. Log in to the Fuel web UI.
#. Select the required OpenStack environment.
#. Go to the :guilabel:`Workflows` tab.
#. In the :guilabel:`Download` column, click on one of the available formats
of the required graph file to download.
**To download a deployment workflow using the Fuel CLI:**
#. Log in to the Fuel Master node CLI.
#. Download the required workflow using the :command:`fuel2 graph download`
command.
**Example:**
.. code-block:: console
fuel2 graph download --env 1 --all
.. seealso::
* :ref:`cli-graphs`

45
userdocs/fuel-user-guide/maintain-environment/workflows-manage/run-workflows.rst Normal file
View File

@@ -0,0 +1,45 @@
.. _run_workflows:
=========================
Run a deployment workflow
=========================
Fuel enables you to execute deployment workflows using the Fuel web UI
or Fuel CLI.
**To execute a deployment workflow using the Fuel web UI:**
#. Log in to the Fuel web UI.
#. Select the required OpenStack environment.
#. Verify that online nodes are added to the environment.
#. Select from the following options:
* To run the default deployment workflow:
#. Go to the :guilabel:`Dashboard` tab.
#. Click :guilabel:`Deploy changes`.
* To run a custom deployment workflow:
#. Upload a custom deployment workflow as described in
:ref:`upload_workflows`.
#. Go to the :guilabel:`Dashboard` tab.
#. Change the deployment mode to :guilabel:`Custom Workflow`
#. Select a particular workflow to run and specify the nodes
the workflow should be executed on.
**To execute a deployment workflow using the Fuel CLI:**
#. Log in to the Fuel CLI.
#. Execute the required workflow using the :command:`fuel2 graph execute`
command.
**Example:**
.. code-block:: console
fuel2 graph execute --env 1
.. seealso::
* :ref:`cli-graphs`

34
userdocs/fuel-user-guide/maintain-environment/workflows-manage/upload-workflows.rst Normal file
View File

@@ -0,0 +1,34 @@
.. _upload_workflows:
============================
Upload a deployment workflow
============================
Fuel enables you to upload deployment workflows using the Fuel web UI or
Fuel CLI.
**To upload a deployment workflow using the Fuel web UI:**
#. Log in to the Fuel web UI.
#. Select the required OpenStack environment.
#. Go to the :guilabel:`Workflows` tab.
#. Click :guilabel:`Upload New Workflow`.
#. In the :guilabel:`Upload New Workflow` dialog, specify the :guilabel:`Name`
and :guilabel:`Type` of the workflow and select the deployment task file from
your file system to upload.
#. Click :guilabel:`Upload`.
**To upload a deployment workflow using the Fuel CLI:**
#. Log in to the Fuel Master node.
#. Upload the required workflow using the :command:`fuel2 graph upload` command.
**Example:**
.. code-block:: console
fuel2 graph upload --env 1 --file tasks.yaml
.. seealso::
* :ref:`cli-graphs`

52
userdocs/fuel-user-guide/maintain-environment/workflows-manage/view-history.rst Normal file
View File

@@ -0,0 +1,52 @@
.. _view_history:
===========================
View the deployment history
===========================
Fuel stores the information about all deployment workflows associated with each
deployment of an environment. You can view the deployment history through
the Fuel web UI (timeline or table view mode) as well as the Fuel CLI.
**To view the deployment history using the Fuel Web UI:**
#. Log in to the Fuel web UI.
#. Select the required OpenStack environment.
#. Select from the following options:
* If you want to view a deployment workflow in progress:
#. Go to the :guilabel:`Dashboard` tab.
#. Click :guilabel:`Show Details` under the deployment progress bar.
* If you want to view the deployment history details of an already deployed
OpenStack environment:
#. Go the :guilabel:`History` tab.
#. Select the required deployment.
**To view the deployment history using the Fuel Web CLI:**
#. Log in to the Fuel Master node.
#. Obtain the ID of the deployment task using one of the following commands:
.. code-block:: console
fuel task
fuel2 task list
#. Get the information on deployment tasks running on nodes:
.. code-block:: console
fuel deployment-tasks --task-id <TASK_ID> --task-name <TASK_NAME> --include-summary --statuses ready, pending --nodes 1,2
fuel2 task history show <TASK_ID> --include-summary --nodes 3 --statuses error skipped
where <TASK-ID> is the ID of the deployment task.
.. warning:: The ``fuel task`` and ``fuel2 task list`` commands show
the Nailgun tasks, such as provisioning, deployment,
verify networks, and so on.
The ``fuel deployment-tasks`` and ``fuel2 task history show``
commands show the deployment tasks running on nodes, such as
database, upload_configuration, hiera, and so on.

28
userdocs/fuel-user-guide/maintain-environment/workflows-manage/view-workflows.rst Normal file
View File

@@ -0,0 +1,28 @@
.. _view_workflows:
================================================
View an environment deployment workflows details
================================================
You can view the deployment details of a specific environment through
the Fuel web UI or Fuel CLI.
**To view the workflows details using the Fuel web UI:**
#. Log in to the Fuel web UI.
#. Select the :guilabel:`Workflows` tab.
**To view the workflows details using the Fuel CLI:**
#. Log in to the Fuel Master node.
#. Type:
.. code-block:: console
fuel2 graph list --env <ENV_ID>
The system response of the :command:`fuel2 graph list` command shows
the table with workflows, their relations, names, and types.
The ``name`` parameter defines additional information about the workflow
and has no impact on business logic.

4
userdocs/fuel-user-guide/manage-environment.rst
View File

@@ -12,6 +12,10 @@ This section includes the following sections:
:maxdepth: 1
manage-environment/cgroups.rst
manage-environment/cgroups/cgroups-configure.rst
manage-environment/cgroups/cgroups-modify-multiple-nodes.rst
manage-environment/cgroups/cgroups-modify-single-node.rst
manage-environment/cgroups/cgroups-example.rst
manage-environment/role-operations.rst
manage-environment/nfv-run.rst
manage-environment/enable-experimental-features.rst

175
userdocs/fuel-user-guide/manage-environment/cgroups.rst
View File

@@ -11,8 +11,10 @@ to the underlying middleware components, such as RabbitMQ, MySQL, and others.
Rational assignment may significantly improve the performance of your system.
Fuel implementation of control groups enables you to create one group for one
process and then create a hierarchy of groups. By default, ``cgroups``
are enabled, but no limits are configured.
process and then create a hierarchy of groups. By default, Fuel enables
``cgroups``, however, Fuel does not configure any limits. You can configure
``cgroups`` using the ``settings.yaml`` file before you deploy an OpenStack
environment or after deployment.
.. note::
Fuel supports control groups only for Ubuntu 14.04. If you have integrated
@@ -22,7 +24,7 @@ are enabled, but no limits are configured.
Fuel supports all standard Linux ``cgroups`` resource controllers, or
subsystems.
However, to optimize the performance of your system you will mostly use
the following resource controllers and limits.
the resource controllers and limits described in the following table.
.. list-table:: **Resource controllers and limits**
:widths: 10 10
@@ -56,7 +58,8 @@ the following resource controllers and limits.
``memory.swappiness``
Controls swap priority. Determines whether kernel can claim memory
from the control group.
from the control group. Set this value to 0 for high memory consuming
processes, such as MySQL, MongoDB, RabbitMQ.
* - ``cpu``
- Controls the use of CPU.
@@ -71,157 +74,27 @@ the following resource controllers and limits.
for all control groups is 100_000. Which means 100%
usage. To restrict the use of CPU, modify this
setting. For example, to use 30% of CPU, change the
value of `cpu.cfs_quota_us`` to 30000.
value of `cpu.cfs_quota_us`` to 30000. Controlling the use of the
CPU resources through the ``cpu.cfs_quota_us`` and
``cpu.cfs_period_us`` parameters provides more accurate resource
allocation compared to using ``cpu.shares``.
You can set the following CPU limits:
* ``beam.smp`` - for RabbitMQ up to 40%.
* ``pangine`` - for Pacemaker up to 10%.
* ``nova-api`` - for Nova 20 - 45%.
* ``nova-conductor`` - for Nova up to 20%.
* ``mysqld`` - for MySQL up to 10%.
* ``neutron-server`` - for Neutron - 10%.
``cpu.shares``
Defines a share of CPU resources available to each control group.
The default value is 1024. For example, if you assign *1024* to one
process and *512* to the other process, kernel proportionally
allocates more CPU for the first process and less for the second.
Using the ``cpu.shares`` parameter to control CPU usage may not
result in accurate CPU resource allocation.
.. _cgroups-configure:
Configure control groups
++++++++++++++++++++++++
You can configure ``cgroups`` for multiple nodes before you deploy an
OpenStack environment by editing the ``settings_1.yaml`` file on the
Fuel Master node.
**To configure control groups:**
#. Log in to the Fuel Master node CLI.
#. Download the Fuel configuration:
.. code-block:: console
fuel settings --env-id <id> --download
#. Open the ``settings_1.yaml`` file for editing.
#. Add the required services to the ``cgroups`` section.
**Example:**
.. code-block:: console
editable:
cgroups:
metadata:
always_editable: true
group: general
label: Cgroups conguration for services
restrictions:
- action: hide
condition: 'true'
weight: 90
mysqld:
label: mysqld
type: text
value: '{"memory":{"memory.swappiness":0,
"memory.soft_limit_in_bytes":"%5, 10, 20"}}'
beam.smp:
label: beam.smp
type: text
value: '{"memory":{"memory.swappiness":0}}'
cinder-api:
label: cinder-api
type: text
value: '{"blkio":{"blkio.weight":500}}'
keystone-api:
label: keystone-api
type: text
value: '{"cpu":{"cpu.shares":70}}'
neutron-server:
label: neutron-server
type: text
value: '{"memory":{"memory.soft_limit_in_bytes":"%total, min, max"}}'
#. Save and exit.
#. Upload the new configuration file to Fuel:
.. code-block:: console
fuel settings --env-id <env_id> --upload
.. _cgroups-modify-multiple-nodes:
Modify control groups for multiple nodes
++++++++++++++++++++++++++++++++++++++++
You can modify ``cgroups`` for a particular process on multiple nodes by
creating a separate file with the ``cgroups`` configuration, uploading
the new configuration file to fuel, and restarting the ``cgroups`` task.
You can modify control groups before or after you deploy an OpenStack
environment.
**To modify control groups for multiple nodes:**
#. Log in to the Fuel Master node CLI.
#. #. Download the Fuel configuration:
.. code-block:: console
fuel settings --env-id <id> --download
#. Open the ``settings.yaml`` file for editing.
#. Copy the ``cgroups`` section.
#. Create a blank ``.yaml`` file.
#. Paster the copied ``cgroups`` configuration into the file.
#. Edit as required.
#. Upload the new configuration file to Fuel:
.. code-block:: console
fuel settings --dir <path_to_new_yaml> --env-id <env_id> --upload
#. Restart the ``cgroups`` task:
.. code-block:: console
fuel node --node-id <node_1> <node_2> <node_3> --tasks cgroups
.. _cgroups-modify-single-node:
Modify control groups for a single node
+++++++++++++++++++++++++++++++++++++++
If you want to change the control group settings on a single node, you must
edit the control groups configuration file ``/etc/cgconfig.conf``, as well
as create, if needed, and configure the ``/etc/cgrules.conf`` file.
You can modify control groups before or after you deploy an OpenStack
environment.
**To modify control groups for a single node:**
#. Log in to the CLI of corresponding node.
#. Open the ``/etc/cgconfig.conf`` file for editing.
#. Apply the required changes.
#. Save and exit.
#. Add the corresponding parameters to the ``/etc/cgrules.conf`` file.
**Example:**
.. code-block:: console
* :keystone-api cpu keystone-api
* :mysqld cpu mysqld
#. Restart ``cgconfigparser``:
.. code-block:: console
service cgconfigparser restart
#. For each running process, type:
.. code-block:: console
cgclassify 'pidof -x <name_of_process>'
#. Restart ``cgrulesengd``:
.. code-block:: console
service cgrulesengd restart
* - ``cpuset``
- Controls the use of memory and processor processes.

Some files were not shown because too many files have changed in this diff Show More