Merge "Reworked the Fuel CLI section"

This commit is contained in:
Jenkins 2016-04-15 06:50:26 +00:00 committed by Gerrit Code Review
commit c7b95aec28
18 changed files with 810 additions and 822 deletions

View File

@ -24,6 +24,19 @@ This section includes the following topics:
:maxdepth: 3
cli/cli_acronyms.rst
cli/cli_usage.rst
cli/cli_basic_usage.rst
cli/cli_management.rst
cli/cli_environment.rst
cli/cli_deploy.rst
cli/cli_network.rst
cli/cli_network_group.rst
cli/cli_network_template.rst
cli/cli_vip.rst
cli/cli_nodes.rst
cli/cli_node_group.rst
cli/cli_roles.rst
cli/cli_plugins.rst
cli/cli_config_openstack.rst
cli/cli_config_openstack_services_workflow.rst
cli/cli_change_ip_range.rst
cli/cli_modify_environment.rst

View File

@ -0,0 +1,44 @@
.. _cli_basic_usage:
Basic usage
-----------
Use the following usage pattern for Fuel commands:
::
fuel [global optional args] <namespace> [action] <optional args>
**Example:**
::
fuel --env-id=1 node set --node-id=1,4,5 --role=controller
.. list-table:: **Fuel commands parameters**
:widths: 10 10
:header-rows: 1
* - Parameter
- Description
* - ``--env-id=1``
- A global argument pointing to a specific environment. This is an
optional parameter.
* - ``node``
- A namespace for all node control functions.
* - ``set``
- An action that assigns nodes with defined roles to specific
environments.
To get the list of all global optional arguments and namespaces, run:
::
fuel --help
To get the list of actions and optional arguments for a namespace, run:
::
fuel <namespace> --help

View File

@ -1,33 +1,33 @@
.. _fuel-cli-config-openstack-services:
.. _cli-config-openstack-services:
Changing the configuration of Nova, Neutron, and Keystone
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Modify the configuration of the OpenStack services
--------------------------------------------------
Using CLI, you can override the hardcoded, or provided by Nailgun,
You can customize the hardcoded, or provided by Nailgun,
configuration values, as well as introduce new configuration options
for OpenStack services.
for the OpenStack services, such as Nova, Neutron, and Keystone using CLI.
You can change the Nova, Neutron, and Keystone configuration for:
You can change the Nova, Neutron, and Keystone configuration for a single
node, all nodes with a specific role, or a whole OpenStack environment.
- A single node
- All nodes with a certain role
- An environment
Changes to the OpenStack services configuration can be applied before
or after you deploy an OpenStack environment.
You can change the configuration before or after the environment deployment.
The services the configuration of which you change restart automatically
after applying the changes.
After you apply changes, the services will be automatically restarted.
The ``override_resources`` Puppet resource applies changes to the existing
configuration resources and creates the new ones that were not previously
defined.
To change the configuration of OpenStack Services
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
**To modify the configuration of the OpenStack services:**
#. Log in to the Fuel Master node.
#. Edit the YAML file with the configuration options of the services that
you are going to change. Example:
#. Edit the ``.yaml`` file with the configuration options of the services that
you want to change.
**Example:**
::
.. code-block:: yaml
@ -43,127 +43,72 @@ To change the configuration of OpenStack Services
DEFAULT/crypt_strength:
value: 6000
#. Upload the YAML file:
#. Upload the ``.yaml`` file:
* To upload the changes for the environment:
* To upload the changes for an OpenStack environment:
.. code-block:: console
fuel openstack-config --env 1 --upload file.yaml
fuel openstack-config --env <env_id> --upload file.yaml
* To upload the changes for all nodes with a role:
* To upload the changes for all nodes with a specific role:
.. code-block:: console
fuel openstack-config --env 1 --role compute --upload file.yaml
fuel openstack-config --env <env_id> --role compute \
--upload <file.yaml>
* To upload the changes for certain nodes:
* To upload the changes for selected nodes:
.. code-block:: console
fuel openstack-config --env 1 --node 1,2,3 --upload file.yaml
fuel openstack-config --env <env_id> --node 1,2,3 \
--upload <file.yaml>
#. Execute the changes:
#. Apply the changes:
* To execute the changes for the environment:
* To apply the changes for the environment:
.. code-block:: console
fuel openstack-config --env 1 --execute
fuel openstack-config --env <env_id> --execute
* To execute the changes for all nodes with a role:
* To apply the changes for all nodes with a role:
.. code-block:: console
fuel openstack-config --env 1 --role compute --execute
fuel openstack-config --env <env_id> --role compute --execute
* To execute the changes for certain nodes:
* To apply the changes for certain nodes:
.. code-block:: console
fuel openstack-config --env 1 --node 1,2,3 --execute
fuel openstack-config --env <env_id> --node 1,2,3 --execute
The services will restart automatically.
#. Optionally, run these additional commands:
**Additional commands**
* List the configuration changes history:
#. List the configuration changes history:
.. code-block:: console
fuel openstack-config --env 1 --list
fuel openstack-config --env <env_id> --list
This command returns a list of configuration changes, each of them with
a respective ID record.
#. Download the previously uploaded ``.yaml`` file with the configuration
changes:
* Download a previously uploaded YAML file with the configuration changes:
#. Obtain the record number from the changes history:
.. code-block:: console
fuel openstack-config --id 1 --download
fuel openstack-config --env <env_id> --list
The ``id`` parameter is the record number from the changes history that
you can get with the :command:`fuel openstack-config --env 1 --list` command.
#. Download the ``.yaml`` file:
**Workflow of the configuration change override**
.. code-block:: console
The ``override_resources`` Puppet resource overrides the already existing
resources and creates the previously not defined resources.
fuel openstack-config --id <id> --download
.. note:: ``override_resources`` must always be used as the first resource
in manifests.
.. seealso::
Example:
.. code-block:: puppet
keystone_config {
'DEFAULT/debug': {value => True}
}
override_resource {'keystone_config':
data => {
'DEFAULT/debug': {'value' => False},
'DEFAULT/max_param_size': {'value' => 128}
}
}
The Nova, Keystone, and Neutron top-level granular tasks use
``override_resources``. The new parameter hash used in the Puppet resources
is passed to ``override_resources`` from hiera.
The three following hiera files cover the hierarchical configuration
overrides:
- ``/etc/hiera/override/config/%{::fqdn}``
- ``/etc/hiera/override/config/role``
- ``/etc/hiera/override/config/cluster``
Hiera delivers the hierarchical structure of data.
The top-level granular tasks used to override the configuration have
the ``refresh_on`` parameter.
Example:
.. code-block:: yaml
- id: keystone
type: puppet
groups: [primary-controller, controller]
required_for: [openstack-controller]
requires: [openstack-haproxy, database, rabbitmq]
refresh_on: [keystone_config]
parameters:
puppet_manifest:
/etc/puppet/modules/osnailyfacter/modular/keystone/keystone.pp
puppet_modules: /etc/puppet/modules
timeout: 3600
test_pre:
cmd: ruby
/etc/puppet/modules/osnailyfacter/modular/keystone/keystone_pre.rb
test_post:
cmd: ruby
/etc/puppet/modules/osnailyfacter/modular/keystone/keystone_post.rb
Nailgun uses the ``refresh_on`` parameter to run the respective task when user changes the
OpenStack configuration.
- :ref:`cli-config-openstack-services-workflow`

View File

@ -0,0 +1,65 @@
.. _cli-config-openstack-services-workflow:
Workflow of the configuration change override
---------------------------------------------
The ``override_resources`` Puppet resource overrides the already existing
resources and creates the resources that have not been defined previously.
.. note:: ``override_resources`` must always be used as the first resource
in manifests.
Example:
.. code-block:: puppet
keystone_config {
'DEFAULT/debug': {value => True}
}
override_resource {'keystone_config':
data => {
'DEFAULT/debug': {'value' => False},
'DEFAULT/max_param_size': {'value' => 128}
}
}
The Nova, Keystone, and Neutron top-level granular tasks use
``override_resources``. The new parameter hash used in the Puppet resources
is passed to ``override_resources`` from Hiera.
The following Hiera files cover the hierarchical configuration
overrides:
- ``/etc/hiera/override/config/%{::fqdn}``
- ``/etc/hiera/override/config/role``
- ``/etc/hiera/override/config/cluster``
Hiera delivers the hierarchical structure of data.
The top-level granular tasks used to override the configuration have
the ``refresh_on`` parameter.
**Example:**
.. code-block:: yaml
- id: keystone
type: puppet
groups: [primary-controller, controller]
required_for: [openstack-controller]
requires: [openstack-haproxy, database, rabbitmq]
refresh_on: [keystone_config]
parameters:
puppet_manifest:
/etc/puppet/modules/osnailyfacter/modular/keystone/keystone.pp
puppet_modules: /etc/puppet/modules
timeout: 3600
test_pre:
cmd: ruby
/etc/puppet/modules/osnailyfacter/modular/keystone/keystone_pre.rb
test_post:
cmd: ruby
/etc/puppet/modules/osnailyfacter/modular/keystone/keystone_post.rb
Nailgun uses the ``refresh_on`` parameter to run the respective
task when you change the OpenStack configuration.

View File

@ -0,0 +1,24 @@
.. _cli-deploy:
Deployment commands
-------------------
The following table describes the deployment commands
available in the Fuel CLI.
.. list-table:: **Deployment commands**
:widths: 10 10 20
: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>``
-

View File

@ -0,0 +1,45 @@
.. _cli-environment:
Environment commands
--------------------
The following table describes environment management commands
available in the Fuel CLI.
.. list-table:: **Environment commands**
:widths: 10 10 20
:header-rows: 1
* - Description
- Command
- Example
* - View the list of environments.
- ``fuel env``
-
* - Create an environment.
- ``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:
::
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:
::
fuel --env <env_id> env set --name <NewEmvName> --mode ha_compact
* - Delete an OpenStack environment.
- ``fuel --env <env_id> env delete``
-
* - Update the Mirantis 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>``
-

View File

@ -0,0 +1,40 @@
.. _cli-management:
Fuel management commands
------------------------
The following table describes basic management commands
available in the Fuel CLI.
.. list-table:: **Management and help commands**
:widths: 10 10 20
:header-rows: 1
* - Description
- Command
- Example
* - View the list of all global optional arguments and namespaces.
- ``fuel --help``
- View the list of actions and optional arguments for a namespace:
.. code-block:: console
fuel <namespace> --help
* - View the list of all available releases
- ``fuel release``
``fuel rel``
- View the information about a specific release:
.. code-block:: console
fuel rel --rel <release_number>
* - Get the information about the Fuel version.
- ``fuel fuel-version``
-
* - Change the Fuel password. You can use the ``--user=admin`` and
``--password=test`` flags to provide user name and password with
all Fuel CLI commands.
- ``fuel user --change-password --new-pass=<new_password>``
-

View File

@ -0,0 +1,69 @@
.. _cli-modify-env:
Modify an Openstack environment using CLI
-----------------------------------------
You can modify your OpenStack environment after deployment
by downloading the ``.yaml`` configuration files, editing settings, and
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
configuration.
If you upload any changes for provisioning or deployment operations,
you freeze the configuration for the entire environment;
any changes you later make to the networks, cluster,
or disk configurations using the Fuel web UI will not be implemented.
To modify these parameters, you must edit the appropriate section of
each node's configuration file and then apply the changes using Fuel CLI.
You can download the following configurations:
* ``network``
* ``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``.
**To modify an OpenStack environment using CLI:**
#. Back up your configuration.
#. Download the ``.yaml`` configuration file(s).
**Example**
::
fuel --env 1 network download
fuel --env 1 settings download
fuel --env 1 deployment default
fuel --env 1 provisioning download
fuel node --node-id 2 --disk --download
#. Modify the downloaded file(s).
#. Save the changes.
#. Upload the files to the Nailgun server:
**Example:**
::
fuel --env 1 provisioning upload
fuel node --node-id 2 --disk --upload
#. Redeploy your OpenStack environment
#. Create a backup of the updated OpenStack environment.
.. note::
You may want to delete the downloaded ``.yaml``
files, as they may contain unencrypted passwords. This
may pose a security threat.

View File

@ -0,0 +1,77 @@
.. _cli-network:
Network commands
----------------
You can manage network configurations using the following command:
.. code-block:: console
fuel --env <ENV_ID> network <action> --dir <PATH>
.. list-table::
:widths: 10 10
:header-rows: 0
* - Value
- Description
* - ``<ENV_ID>``
- ID of an OpenStack environment
* - ``<PATH>``
- Path to directory
* - <action>
- Action that will be performed for the network configuration.
The following table describes network management commands
available in the Fuel CLI.
.. list-table:: **Network management commands**
:widths: 10 10 20
:header-rows: 1
* - Command
- Description
- Example
* - ``fuel --env <ENV_ID> network --download --dir <PATH>``
- Download network configuration for a specific environment.
- Download network configuration for
the environment with ID ``1`` to the current directory:
.. code-block:: console
fuel --env 1 network --download
* - ``fuel --env <ENV_ID> network --upload --dir <PATH>``
- Upload network configuration for a specific environment.
- Upload network configuration for the environment with
ID ``1`` from the current directory:
.. code-block:: console
fuel --env 1 network --upload
.. note::
The :command:`fuel network` command can update configuration of
all networks in an OpenStack environment, as well as corresponding
Neutron parameters. However, you must update the related VIPs
and network templates separately using the corresponding Fuel
CLI commands.
* - ``fuel --env <ENV_ID> network --verify --dir <PATH>``
- Verify network configuration. Verification does not work for
multiple cluster networks, when an environment has more than one
node group.
- Verify network configuration of the OpenStack environment with ID ``1``
from the current directory:
.. code-block:: console
fuel --env 1 network --verify
To view interaction with the Nailgun API, run the corresponding command with
the :option:`--debug` option.
**Example:**
.. code-block:: console
fuel --env <ENV_ID> network --download --dir <PATH> --debug

View File

@ -0,0 +1,70 @@
.. _cli-network-group:
Network group management commands
---------------------------------
The following table describes network group management commands
available in the Fuel CLI.
.. list-table:: **Network group management commands**
:widths: 10 10 20
:header-rows: 1
* - Description
- Command
- Example
* - List all available network groups.
- ``fuel network-group``
-
* - List network groups in a particular node group.
- ``fuel network-group --node-group <GROUP_ID>``
- .. code-block:: console
fuel network-group --node-group 1
* - Create a new network group.
Variables:
* ``<NODE_GROUP_ID>`` - an ID of a node group
* ``<NAME>`` - a name of a new network group
* ``<RELEASE_ID>`` - a release ID this network group belongs to
* ``<VLAN_ID>`` - a VLAN of a network
* ``<CIDR>`` - a CIDR of a network
* ``<GATEWAY_IP>`` - a gateway of a network
* ``<META_INFO>`` - meta information in JSON format
- ``fuel network-group --create --node-group <NODE_GROUP_ID> --name \
<NAME> --release <RELEASE_ID> --vlan <VLAN_ID> --cidr <CIDR> --gateway \
<GATEWAY_IP> --meta <META_INFO>``
- .. code-block:: console
fuel network-group --create --node-group 2 --name "new network" \
--release 2 --vlan 100 --cidr 10.0.0.0/24 --gateway 10.0.0.1 \
--meta 'meta information in JSON format'
* - Set parameters for a network group.
Variables:
* ``<ID>`` - an ID of a network group
* ``<PARAMETER>`` - a parameter you want to set or update.
See the ``fuel network-group --create`` command for the
list of parameters.
* ``<NEW_VALUE>`` - a new value for the specified parameter
- ``fuel network-group --set --network <ID> --<PARAMETER> <NEW_VALUE>``
- .. code-block:: console
fuel network-group --set --network 1 --name new_name
* - Delete a network group.
- ``fuel network-group --delete --network <GROUP_ID>``
- Delete a single network group:
.. code-block:: console
fuel network-group --delete --network 1
Delete multiple network groups:
.. code-block:: console
fuel network-group --delete --network 2,3,4

View File

@ -0,0 +1,31 @@
.. _cli-network-template:
Network template management commands
------------------------------------
The following table describes network template management commands
available in the Fuel CLI.
.. list-table:: **Network template management commands**
:widths: 10 10 20
:header-rows: 1
* - Description
- Command
- Example
* - Upload a network template.
- ``fuel --env <ENV_ID> network-template --upload --dir <PATH>``
- .. code-block:: console
fuel --env 1 network-template --upload --dir /home/stack/
* - Download a network template to the current directory.
- ``fuel --env <ENV_ID> network-template --download``
- .. code-block:: console
fuel --env 1 network-template --download
* - Delete a network template.
- ``fuel --env <ENV_ID> network-template --delete``
- .. code-block:: console
fuel --env 1 network-template --delete

View File

@ -0,0 +1,35 @@
.. _cli-node-group:
Node group management commands
------------------------------
The following table describes node group management commands
available in the Fuel CLI.
.. list-table:: **Node group management commands**
:widths: 10 10 20
:header-rows: 1
* - Description
- Command
- Example
* - List all available node groups.
- ``fuel nodegroup``
- List node groups for a specific OpenStack environment:
::
fuel --env <env_id> nodegroup
* - Create a node group.
- ``fuel --env <env_id> nodegroup --create --name "group_name"``
- ::
fuel --env <env_id> nodegroup --create --name "group 1"
* - Delete a node group.
- ``fuel --env <env_id> nodegroup --delete --group <group_id>``
-
* - Assign a node to a specific node group.
- ``fuel --env <env_id> nodegroup --assign --node <node_id> --group
<group_id>``
-

View File

@ -0,0 +1,52 @@
.. _cli-nodes:
Node management commands
------------------------
The following table describes node management commands
available in the Fuel CLI.
.. list-table:: **Node management commands**
:widths: 10 10 20
:header-rows: 1
* - Description
- Command
- Example
* - List all available nodes.
- ``fuel node list``
- List nodes for a specific environment:
::
fuel --env-id <env_id> node list
* - Assign nodes with specific roles to an OpenStack environment.
- ``fuel node set --node <node_id> --role <role> --env <env_id>``
- ::
fuel node set --node <node_id> --role controller --env <env_id>
::
fuel node set --node <node1_id>,<node2_id>,<node3_id> \
--role compute,cinder --env <env_id>
* - Remove nodes from an OpenStack environment.
- ``fuel node remove --node <node1_id>,<node2_id> --env <env_id>``
- Remove nodes without specifying an OpenStack environment:
::
fuel node remove --node <node1_id>,<node2_id>
Remove all nodes from a specific OpenStack environment:
::
fuel node remove --env <env_id>
* - Delete nodes with the *offline* status from the Fuel database.
- ``fuel node --node-id <id> --delete-from-db``
- Delete nodes with any status from the Fuel database:
::
fuel node --node-id <id> --delete-from-db --force

View File

@ -0,0 +1,56 @@
.. _cli_plugins:
Plugin management commands
--------------------------
The following table describes the plugin management commands
available in the Fuel CLI.
.. note::
To view the list of all available options, use the
``fuel plugins --help`` command.
.. list-table:: **Plugin management commands**
:widths: 10 10 20
:header-rows: 1
* - Description
- Command
- Example
* - Install a Fuel plugin from an ``.fp`` package.
- `` 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
``yum install`` from an ``.rpm`` package in Nailgun.
- ``fuel plugins --register <fuel-plugin-name>==<fuel-plugin-version>``
-
* - View the list of installed plugins.
- ``fuel plugins --list``
- ::
fuel plugins --list
**System response:**
::
id | name | version | package_version
---|---------------------------|----------|----------------
1 | <fuel-plugin-name> | 1.0.0 | 2.0.0
* - Remove a plugin.
- ``fuel plugins --remove <fuel-plugin-name>==<fuel-plugin-version>``
-
* - Upgrade a Fuel plugin installed from the ``.rpm`` package.
.. note::
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
1.0.0 to 1.0.1.
- fuel plugins --update <fuel-plugin-file>
-

View File

@ -0,0 +1,88 @@
.. _cli-roles:
Role management commands
------------------------
Fuel CLI implements standard CRUD for operations on a node role.
The following table describes the role management commands
available in the Fuel CLI.
.. list-table:: **Role operations commands**
:widths: 10 10 20
:header-rows: 1
* - Description
- Command
- Example
* - List roles.
- ``fuel role --rel <release_id>``
- ::
fuel role --rel 2
**System response:**
::
name | id
--------------|---
controller | 9
compute | 10
cinder | 11
cinder-vmware | 12
ceph-osd | 13
mongo | 14
zabbix-server | 15
base-os | 16
* - Create a new role from the ``.yaml`` file.
- ``fuel role --rel <2> --create --file <file.yaml>``
- #. Create a role in a ``.yaml`` file.
The following text is an example of a .yaml file for the Swift
role:
::
meta:
description: Installs swift server.
has_primary: true # we need primary-swift and swift during
orchestration
name: Swift
name: swift
volumes_roles_mapping:
- allocate_size: min
id: os
#. Assign the role:
::
fuel role --rel <2> --create --file <swift.yaml>
#. View the role:
::
fuel role --rel <2>
**System response:**
::
name | id
--------
swift | 17
* - Update the role data
- `` fuel role --rel <release_id> --update --file <file>``
- ::
fuel role --rel <2> --update --file <swift.yaml>
* - Delete the role.
- ``fuel role --rel <release_id> --delete --role <file>``
- ::
fuel role --rel <2> --delete --role <swift>
line 573

View File

@ -1,699 +0,0 @@
.. _cli_usage:
Basic usage
-----------
Fuel CLI has the following usage pattern:
::
fuel [global optional args] <namespace> [action] <optional args>
*Example*::
fuel --env-id=1 node set --node-id=1,4,5 --role=controller
where ``--env-id=1`` is a global optional argument pointing to the specific
environment, ``node`` - is a namespace for all node control functions, ``set``
is an action that assigns specific nodes to some environments in certain roles.
To get the list of all global optional arguments and namespaces, run:
::
fuel --help
To get the list of actions and optional arguments for a namespace, run:
::
fuel <namespace> --help
Release
+++++++
Get list of all available releases:
::
fuel release
or short version
::
fuel rel
for specific release
::
fuel rel --rel <release_number>
Version
+++++++
To get all the details on the Fuel environment installed, run the
following command::
fuel fuel-version
.. warning::
The argument ``--fuel-version`` will be deprecated since the Fuel
7.0 release. Please use :command:`fuel-version` command instead.
Networks configuration
++++++++++++++++++++++
Download a network configuration for a specific environment:
.. code-block:: console
fuel --env <ENV_ID> network --download --dir <PATH>
where:
* ``<ENV_ID>`` - an environment ID
* ``<PATH>`` - a path to directory
For example, download the network configuration for
the environment with ID ``1`` to the current directory:
.. code-block:: console
fuel --env 1 network --download
Upload a network configuration for a specific environment:
.. code-block:: console
fuel --env <ENV_ID> network --upload --dir <PATH>
For example, upload the network configuration for
the environment with ID ``1`` from the current directory:
.. code-block:: console
fuel --env 1 network --upload
.. note::
The :command:`fuel network` command can update a configuration
for all networks in an environment and Neutron parameters,
but it does not update VIPs and network templates. You have to
update VIPs and network templates additionally using
corresponding Fuel CLI commands.
Verify a network configuration for a specific environment:
.. code-block:: console
fuel --env <ENV_ID> network --verify --dir <PATH>
For example, verify the network configuration for
the environment with ID ``1`` from the current directory:
.. code-block:: console
fuel --env 1 network --verify
.. note::
Verification does not work for multiple cluster networks, when
an environment has more than one node group.
To see interaction with Nailgun API, run the commands with
the :option:`--debug` option:
.. code-block:: console
fuel --env <ENV_ID> network --download --dir <PATH> --debug
fuel --env <ENV_ID> network --upload --dir <PATH> --debug
fuel --env <ENV_ID> network --verify --dir <PATH> --debug
Environment
+++++++++++
To list environments:
::
fuel env
To create an environment, run the following command using
``--name`` and ``--rel`` (release) options:
::
fuel env create --name <env_name> --rel <release_number>
By default it creates environment in ``multinode`` mode, and ``nova`` network mode.
To specify other modes, you can add optional arguments; for example:
::
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 the environment; for example:
::
fuel --env <env_id> env set --name <NewEmvName> --mode ha_compact
To delete the environment:
::
fuel --env <env_id> env delete
To update the OpenStack environment to a newer version
(available since Fuel 5.1):
::
fuel env --update --env <env_id> --rel <release_number>
To roll back a failed update,
use this same command but modify the release ID.
Node
++++
To list all available nodes run:
::
fuel node list
and filter them by environment:
::
fuel --env-id <env_id> node list
Assign some nodes to environment with with specific roles
::
fuel node set --node <node_id> --role controller --env <env_id>
fuel node set --node <node1_id>,<node2_id>,<node3_id> \
--role compute,cinder --env <env_id>
Remove some nodes from environment
::
fuel node remove --node <node1_id>,<node2_id> --env <env_id>
Also you can do it without ``--env`` or ``--node`` to remove some nodes without knowing their environment and remove all nodes of some environment respectively.
::
fuel node remove --node <node1_id>,<node2_id>
fuel node remove --env <env_id>
.. _remove-inv:
Delete nodes from Fuel DB.
* Remove offline nodes:
::
fuel node --node-id <id> --delete-from-db
fuel node --node-id <id1> <id2> --delete-from-db
* Remove nodes with any status (``--force`` option forces deletion
of nodes regardless of their state):
::
fuel node --node-id <id> --delete-from-db --force
.. _fuel-cli-node-group:
Node group
++++++++++
To list all available node groups:
::
fuel nodegroup
and filter them by environment:
::
fuel --env <env_id> nodegroup
Create a new node group
::
fuel --env <env_id> nodegroup --create --name "group 1"
Delete the specified node groups
::
fuel --env <env_id> nodegroup --delete --group <group_id>
fuel --env <env_id> nodegroup --delete --group <group1_id>,<group2_id>,<group3_id>
Assign nodes to the specified node group:
::
fuel --env <env_id> nodegroup --assign --node <node_id> --group <group_id>
fuel --env <env_id> nodegroup --assign --node <node1_id>,<node2_id>,<node3_id> --group <group_id>
.. _network_template_operations:
Network Template
++++++++++++++++
To upload a network template, run the following
command on the Fuel Master node:
.. code-block:: console
fuel --env <ENV_ID> network-template --upload --dir <PATH>
where:
* ``<ENV_ID>`` - an ID of your OpenStack environment that you
can get by running the :command:`fuel environment` command
* ``<PATH>`` - a path to a directory where your template is located
For example:
.. code-block:: console
fuel --env 1 network-template --upload --dir /home/stack/
Download a network template to the current directory:
.. code-block:: console
fuel --env <ENV_ID> network-template --download
For example:
.. code-block:: console
fuel --env 1 network-template --download
Delete an existing network template:
.. code-block:: console
fuel --env <ENV_ID> network-template --delete
For example:
.. code-block:: console
fuel --env 1 network-template --delete
.. _network_group_operations:
Network Group
+++++++++++++
List all available network groups:
.. code-block:: console
fuel network-group
List network groups in a particular node group:
.. code-block:: console
fuel network-group --node-group <GROUP_ID>
For example:
.. code-block:: console
fuel network-group --node-group 1
Create a new network group:
.. code-block:: console
fuel network-group --create --node-group <NODE_GROUP_ID> --name <NAME> \
--release <RELEASE_ID> --vlan <VLAN_ID> --cidr <CIDR> --gateway <GATEWAY_IP> \
--meta <META_INFO>
where:
* ``<NODE_GROUP_ID>`` - an ID of a node group
* ``<NAME>`` - a name of a new network group
* ``<RELEASE_ID>`` - a release ID this network group belongs to
* ``<VLAN_ID>`` - a VLAN of a network
* ``<CIDR>`` - a CIDR of a network
* ``<GATEWAY_IP>`` - a gateway of a network
* ``<META_INFO>`` - meta information in JSON format
For example:
.. code-block:: console
fuel network-group --create --node-group 1 --name "new network" \
--release 2 --vlan 100 --cidr 10.0.0.0/24
fuel network-group --create --node-group 2 --name "new network" \
--release 2 --vlan 100 --cidr 10.0.0.0/24 --gateway 10.0.0.1 \
--meta 'meta information in JSON format'
Set parameters for the specified network group:
.. code-block:: console
fuel network-group --set --network <ID> --<PARAMETER> <NEW_VALUE>
where:
* ``<ID>`` - an ID of a network group
* ``<PARAMETER>`` - a parameter you want to set or update.
See the ``fuel network-group --create`` command for the
list of parameters.
* ``<NEW_VALUE>`` - a new value for the specified parameter
For example:
.. code-block:: console
fuel network-group --set --network 1 --name new_name
Delete network groups:
.. code-block:: console
fuel network-group --delete --network <GROUP_ID>
For example:
.. code-block:: console
fuel network-group --delete --network 1
You can also delete multiple groups:
.. code-block:: console
fuel network-group --delete --network 2,3,4
.. _vip-operations:
Virtual IP
++++++++++
Download a virtual IP (VIP) configuration for a specific environment to a specified file:
.. code-block:: console
fuel --env <ENV_ID> vip --download --file <FILE_NAME>
where:
* ``<ENV_ID>`` - an environment ID
* ``<FILE_NAME>`` - a name of the ``yaml`` file where to save a VIP configuration (optional)
For example:
.. code-block:: console
fuel --env 1 vip --download --file vip.yaml
Upload a VIP configuration for a specific environment from a specified file:
.. code-block:: console
fuel --env <ENV_ID> vip --upload --file <FILE>
For example:
.. code-block:: console
fuel --env 1 vip --upload --file vip.yaml
.. _roles-operations:
Roles operations
++++++++++++++++
CLI basically implements standard CRUD for operating on a role.
* List a role:
::
fuel role --rel 2
name | id
--------------|---
controller | 9
compute | 10
cinder | 11
cinder-vmware | 12
ceph-osd | 13
mongo | 14
zabbix-server | 15
base-os | 16
* Create a new role.
- In this example,
we first create a swift role in ``swift.yaml``:
::
meta:
description: Installs swift server.
has_primary: true # we need primary-swift and swift during orchestration
name: Swift
name: swift
volumes_roles_mapping:
- allocate_size: min
id: os
- Then use ``--create`` flag to proceed. When created,
you can start using a new role for your own tasks:
::
fuel role --rel <2> --create --file <swift.yaml>
fuel role --rel <2>
name | id
--------
swift | 17
* Update role data:
::
fuel role --rel <2> --update --file <swift.yaml>
* Delete the role:
::
fuel role --rel <2> --delete --role <swift>
.. _fuel-cli-config:
Configuring
+++++++++++
Configuration of the environment or some node
is universal and done in three stages:
1. Download current or default configuration. Works for
(``network``, ``settings``, ``node --disk``, ``node --network``).
Operations with ``deployment`` and ``provisioning`` can be node
specific. (e.g. ``fuel --env 1 deployment --node-id=1,2``)
*Example*::
fuel --env 1 network download
fuel --env 1 settings download
fuel --env 1 deployment default
fuel --env 1 provisioning download
fuel node --node-id 2 --disk --download
2. Modify the downloaded ``.yaml`` files
with your favorite text editor.
3. Upload files to Nailgun server
After redeploying your environment with the new configuration,
you should create a new backup
of the Fuel Master node.
You may also want to delete the ``.yaml`` files
since you can easily regenerate them at any time.
Some of the generated ``yaml`` files
contain unencrypted passwords
whose presence on disk may constitute a security threat.
*Example*::
fuel --env 1 provisioning upload
fuel node --node-id 2 --disk --upload
.. note::
To protect yourself when using the Fuel CLI to modify configurations,
note the following:
* Back up
all your configurations before you begin any modifications.
* If you remove something from a configuration file,
be sure you do not need it;
Fuel CLI overwrites the old data with the new
rather than merging new data with existing data.
* If you upload any changes for provisioning or deployment operations,
you freeze the configuration for the entire environment;
any changes you later make to the networks, cluster settings,
or disk configurations using the Fuel Web UI are not implemented.
To modify such parameters,
you must edit the appropriate section of each node's configuration
and apply the changes with Fuel CLI.
Deployment
++++++++++
For acronyms meaning,
see :ref:`cli-acronyms`.
You can deploy environment changes with:
::
fuel --env <env_id> deploy-changes
Also, you can deploy and provision only some nodes like this
::
fuel node --provision --node <node1_id>,<node2_id>
fuel node --deploy --node <node1_id>,<node2_id>
.. _cli-fuel-password:
Change and Set Fuel password
++++++++++++++++++++++++++++
You can change the Fuel Master Node password
with either of the following:
::
fuel user --change-password --new-pass=<new_password>
Note that **change-password** option
can also be used without preceding hyphens.
You can use flags to provide username and password
to other fuel CLI commands:
::
--user=admin --password=test
.. note: In Release 5.1 and earlier, the **--os-username**
and ``os-password`` options are used
rather than ``user`` and ``--change-password``.
These options are not supported in Releases 5.1.1 and later.
.. _fuel-plugins-cli:
Fuel Plugins CLI
++++++++++++++++
* To install a Fuel plugin:
1. Select from the following options:
* If you install a Fuel plugin from an `.fp` package, type:
.. code-block:: bash
fuel plugins --install <fuel-plugin-file>
* If you install a Fuel plugin from an `.rpm` package, select from the
following options:
* Using ``yum install``:
1. Install the Fuel plugin:
.. code-block:: bash
yum install <fuel-plugin-file>
2. Register the plugin in Nailgun:
.. code-block:: bash
fuel plugins --register <fuel-plugin-name>==<fuel-plugin-version>
* Using the same command you used to install a Fuel plugin from the
`.fp` package:
.. code-block:: bash
fuel plugins --install <fuel-plugin-file>
2. View the list of installed plugins:
.. code-block:: bash
fuel plugins --list
id | name | version | package_version
---|---------------------------|----------|----------------
1 | <fuel-plugin-name> | 1.0.0 | 2.0.0
* To remove a plugin, type:
.. code-block:: bash
fuel plugins --remove <fuel-plugin-name>==<fuel-plugin-version>
* To upgrade a Fuel RPM plugin, type:
.. code-block:: bash
fuel plugins --update <fuel-plugin-file>
.. note:: Upgradess are *not* supported for:
* fp plugins
* major versions of RPM plugins
For example, you can only upgrade from version 1.0.0 to 1.0.1.
To see the list of all available options, use ``fuel plugins --help`` command.

View File

@ -0,0 +1,34 @@
.. _cli-vip:
Virtual IP management commands
------------------------------
The following table describes virtual IP management commands
available in the Fuel CLI.
.. list-table:: **Virtual IP management commands**
:widths: 10 10 20
:header-rows: 1
* - Description
- Command
- Example
* - Download a virtual IP (VIP) configuration for a specific environment
to a specified file.
Variables:
* ``<ENV_ID>`` - an environment ID
* ``<FILE_NAME>`` - a name of the ``yaml`` file where to save a VIP
configuration (optional).
- `` 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>``
- .. code-block:: console
fuel --env 1 vip --upload --file vip.yaml

View File

@ -7,8 +7,7 @@ you can create, update or delete roles
using Nailgun
REST API and Fuel Client.
For Fuel CLI command reference, see
:ref:`Role operations <roles-operations>`.
For Fuel CLI command reference, see :ref:`cli-roles`.
This section provides the Controller
role example: