diff --git a/doc/source/backup/kubernetes/system-backup-running-ansible-restore-playbook-remotely.rst b/doc/source/backup/kubernetes/system-backup-running-ansible-restore-playbook-remotely.rst index 099dbc1e0..92d1d68dd 100644 --- a/doc/source/backup/kubernetes/system-backup-running-ansible-restore-playbook-remotely.rst +++ b/doc/source/backup/kubernetes/system-backup-running-ansible-restore-playbook-remotely.rst @@ -78,7 +78,7 @@ In this method you can run Ansible Restore playbook and point to controller-0. .. code-block:: none - -e backup\_filename= localhost_platform_backup_2019_07_15_14_46_37.tgz + -e backup_filename= localhost_platform_backup_2019_07_15_14_46_37.tgz - The initial_backup_dir is the location on the Ansible control machine where the platform backup tar file is placed to restore the diff --git a/doc/source/fault-mgmt/kubernetes/viewing-active-alarms-using-the-cli.rst b/doc/source/fault-mgmt/kubernetes/viewing-active-alarms-using-the-cli.rst index 1886e41d0..3d2f39ec5 100644 --- a/doc/source/fault-mgmt/kubernetes/viewing-active-alarms-using-the-cli.rst +++ b/doc/source/fault-mgmt/kubernetes/viewing-active-alarms-using-the-cli.rst @@ -64,27 +64,27 @@ To review detailed information about a specific alarm instance, see | | | | | ~(keystone_admin)$ fm alarm-list --query uuid=4ab5698a-19cb... | +-----------------------------------------------------+----------------------------------------------------------------------------+ - | :command:`alarm\_id=` | Query alarms by alarm ID, for example: | + | :command:`alarm_id=` | Query alarms by alarm ID, for example: | | | | | | .. code-block:: none | | | | | | ~(keystone_admin)$ fm alarm-list --query alarm_id=100.104 | +-----------------------------------------------------+----------------------------------------------------------------------------+ - | :command:`alarm\_type=` | Query alarms by type, for example: | + | :command:`alarm_type=` | Query alarms by type, for example: | | | | | | .. code-block:: none | | | | | | ~(keystone_admin)$ fm alarm-list --query \ | | | alarm_type=operational-violation | +-----------------------------------------------------+----------------------------------------------------------------------------+ - | :command:`entity\_type\_id=` | Query alarms by entity type ID, for example: | + | :command:`entity_type_id=` | Query alarms by entity type ID, for example: | | | | | | .. code-block:: none | | | | | | ~(keystone_admin)$ fm alarm-list --query \ | | | entity_type_id=system.host | +-----------------------------------------------------+----------------------------------------------------------------------------+ - | :command:`entity\_instance\_id=` | Query alarms by entity instance id, for example: | + | :command:`entity_instance_id=` | Query alarms by entity instance id, for example: | | | | | | .. code-block:: none | | | | @@ -117,17 +117,17 @@ To review detailed information about a specific alarm instance, see UUID can be used in display alarm details with the :command:`fm alarm-show` command. - **--include\_suppress** + **--include_suppress** Use this option to include suppressed alarms in the list. - **--mgmt\_affecting** + **--mgmt_affecting** Management affecting alarms prevent some critical administrative actions from being performed. For example, software upgrades. Using the - ``--mgmt\_affecting`` option will list an additional column in the output, + ``--mgmt_affecting`` option will list an additional column in the output, 'Management Affecting', which indicates whether the alarm is management affecting or not. - **--degrade\_affecting** + **--degrade_affecting** Include degrade affecting status in output. The following example shows alarm UUIDs. diff --git a/doc/source/system_configuration/openstack/system-configuration-overview.rst b/doc/source/system_configuration/openstack/system-configuration-overview.rst index f2672611d..385ce81fd 100644 --- a/doc/source/system_configuration/openstack/system-configuration-overview.rst +++ b/doc/source/system_configuration/openstack/system-configuration-overview.rst @@ -89,11 +89,11 @@ The optional arguments are: ``--reset-values`` Replace any existing helm chart overrides with the ones specified. -``--values `` +``--values `` Specify a YAML file containing helm chart override values. Can specify multiple times. -``--set `` +``--set `` Set helm chart override values on the command line. Multiple override values can be specified with multiple ``--set`` arguments. These are processed after ``--values`` files.