[UG] The Manage workflows section

Change-Id: Ief92bbafba3cca9ab919c8a0577266d8910541c8
This commit is contained in:
OlgaGusarenko 2016-09-13 09:30:25 +03:00 committed by Olga Gusarenko
parent e4b48efedb
commit 39aa29daf9
15 changed files with 307 additions and 201 deletions

View File

@ -25,7 +25,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,6 +35,10 @@ 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>]``

View File

@ -34,16 +34,6 @@ minutes to an hour.
select nodes.
#. Click :guilabel:`Deploy Nodes`.
**To view the deployment details in the Fuel web UI:**
.. seealso::
#. Select from the following options:
* If you want to view a deployment task in progress:
#. Select the :guilabel:`Dashboard` tab.
#. Click :guilabel:`Show Details` under the deployment progress bar.
* If you want to view details about a deployed OpenStack environment:
#. Select the :guilabel:`History` tab.
#. Select the required deployment.
* :ref:`view_workflows`

View File

@ -1,5 +1,6 @@
.. _maintain-environment:
===================================
Maintain your OpenStack environment
===================================
@ -21,9 +22,7 @@ This section includes the following topics:
maintain-environment/reinstall-node.rst
maintain-environment/reinstall-virtual-role.rst
maintain-environment/create-snapshot.rst
maintain-environment/custom-graph.rst
maintain-environment/manage-workflows.rst
maintain-environment/data-driven.rst
maintain-environment/deployment-history.rst
maintain-environment/deployment-information.rst
maintain-environment/shutdown-env.rst
maintain-environment/start-env.rst
maintain-environment/start-env.rst

View File

@ -1,112 +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.
The 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.

View File

@ -1,36 +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.

View File

@ -1,32 +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.

View File

@ -0,0 +1,25 @@
.. _manage_workflows:
===============
Manage workfows
===============
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
manage-workflows/workflows-precedence.rst
manage-workflows/view-workflows.rst
manage-workflows/upload-workflows.rst
manage-workflows/download-workflows.rst
manage-workflows/run-workflows.rst
manage-workflows/view-history.rst
manage-workflows/download-deployment-info.rst

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.

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`

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`

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`

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.

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.

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

View File

@ -36,13 +36,13 @@ This section lists these improvements:
* Fuel now stores detailed information about all deployments. You can download
the actual cluster settings, network configuration, and serialized cluster
data.
See :ref:`deployment-history` and :ref:`deployment-information`.
See :ref:`view_history` and :ref:`deployment-information`.
* You can now execute a particular deployment graph with the ability to merge
it with the existing deployment graphs of the upstream master release.
* You can now execute a particular deployment workflow with the ability to merge
it with the existing deployment workflows of the upstream master release.
This allows you to implement complex orchestrated workflows -- bugfixes
application, reference architecture altering, or even upgrades.
See :ref:`custom-graph`.
See :ref:`manage_workflows`.
* Fuel now supports lifecycle management tasks based on the history of
cluster states. This data-driven feature allows the deployment engineers