Fix errors and add to index

Author: seunghun1ee

doc/source/operations/baremetal-node-management.rst

@@ -181,7 +181,7 @@ The command below extracts a list of port UUID, node UUID and switch port inform
 
 .. code-block:: bash
 
-   admin# openstack baremetal port list --field uuid --field node_uuid --field local_link_connection --format value
+    openstack baremetal port list --field uuid --field node_uuid --field local_link_connection --format value
 
 NGS will manage VLAN membership for ports when the ``local_link_connection`` fields match one of the switches in ``ml2_conf.ini``.
 The rest of the switch configuration is static.

doc/source/operations/ceph-management.rst

@@ -45,8 +45,8 @@ Ceph commands are usually run inside a ``cephadm shell`` utility container:
 
 .. code-block:: console
 
-   # From the node that runs Ceph
-   ceph# sudo cephadm shell
+   # From storage host
+   sudo cephadm shell
 
 Operating a cluster requires a keyring with an admin access to be available for Ceph
 commands. Cephadm will copy such keyring to the nodes carrying
@@ -71,15 +71,17 @@ First drain the node
 
 .. code-block:: console
 
-   ceph# cephadm shell
-   ceph# ceph orch host drain <host>
+   # From storage host
+   sudo cephadm shell
+   ceph orch host drain <host>
 
 Once all daemons are removed - you can remove the host:
 
 .. code-block:: console
 
-   ceph# cephadm shell
-   ceph# ceph orch host rm <host>
+   # From storage host
+   sudo cephadm shell
+   ceph orch host rm <host>
 
 And then remove the host from inventory (usually in
 ``etc/kayobe/inventory/overcloud``)
@@ -98,24 +100,27 @@ movement:
 
 .. code-block:: console
 
-   ceph# cephadm shell
-   ceph# ceph osd set noout
+   # From storage host
+   sudo cephadm shell
+   ceph osd set noout
 
 Reboot the node and replace the drive
 
 Unset noout after the node is back online
 
 .. code-block:: console
 
-   ceph# cephadm shell
-   ceph# ceph osd unset noout
+   # From storage host
+   sudo cephadm shell
+   ceph osd unset noout
 
 Remove the OSD using Ceph orchestrator command:
 
 .. code-block:: console
 
-   ceph# cephadm shell
-   ceph# ceph orch osd rm <ID> --replace
+   # From storage host
+   sudo cephadm shell
+   ceph orch osd rm <ID> --replace
 
 After removing OSDs, if the drives the OSDs were deployed on once again become
 available, cephadm may automatically try to deploy more OSDs on these drives if
@@ -142,7 +147,7 @@ identify which OSDs are tied to which physical disks:
 
 .. code-block:: console
 
-   ceph# ceph device ls
+   ceph device ls
 
 Host maintenance
 ----------------
@@ -167,7 +172,7 @@ Ceph can report details about failed OSDs by running:
 
 .. code-block:: console
 
-   ceph# ceph health detail
+   ceph health detail
 
 .. note ::
 
@@ -184,15 +189,16 @@ A failed OSD will also be reported as down by running:
 
 .. code-block:: console
 
-   ceph# ceph osd tree
+   ceph osd tree
 
 Note the ID of the failed OSD.
 
 The failed disk is usually logged by the Linux kernel too:
 
 .. code-block:: console
 
-   storage-0# dmesg -T
+   # From storage host
+   dmesg -T
 
 Cross-reference the hardware device and OSD ID to ensure they match.
 (Using `pvs` and `lvs` may help make this connection).
@@ -207,36 +213,35 @@ show``).
 On this hypervisor, enter the libvirt container:
 
 .. code-block:: console
-   :substitutions:
 
-   |hypervisor_hostname|# docker exec -it nova_libvirt /bin/bash
+   # From hypervisor host
+   docker exec -it nova_libvirt /bin/bash
 
 Find the VM name using libvirt:
 
 .. code-block:: console
-   :substitutions:
 
-   (nova-libvirt)[root@|hypervisor_hostname| /]# virsh list
+   (nova-libvirt)[root@compute-01 /]# virsh list
     Id    Name                State
    ------------------------------------
     1     instance-00000001   running
 
 Now inspect the properties of the VM using ``virsh dumpxml``:
 
 .. code-block:: console
-   :substitutions:
 
-   (nova-libvirt)[root@|hypervisor_hostname| /]# virsh dumpxml instance-00000001 | grep rbd
-         <source protocol='rbd' name='|nova_rbd_pool|/51206278-e797-4153-b720-8255381228da_disk'>
+   (nova-libvirt)[root@compute-01 /]# virsh dumpxml instance-00000001 | grep rbd
+         <source protocol='rbd' name='<nova rbd pool>/51206278-e797-4153-b720-8255381228da_disk'>
 
 On a Ceph node, the RBD pool can be inspected and the volume extracted as a RAW
 block image:
 
 .. code-block:: console
-   :substitutions:
 
-   ceph# rbd ls |nova_rbd_pool|
-   ceph# rbd export |nova_rbd_pool|/51206278-e797-4153-b720-8255381228da_disk blob.raw
+   # From storage host
+   sudo cephadm shell
+   rbd ls <nova rbd pool>
+   rbd export <nova rbd pool>/51206278-e797-4153-b720-8255381228da_disk blob.raw
 
 The raw block device (blob.raw above) can be mounted using the loopback device.
 
@@ -248,8 +253,9 @@ libguestfs-tools and using the guestfish command:
 
 .. code-block:: console
 
-   ceph# export LIBGUESTFS_BACKEND=direct
-   ceph# guestfish -a blob.qcow
+   # From storage host
+   export LIBGUESTFS_BACKEND=direct
+   guestfish -a blob.qcow
    ><fs> run
     100% [XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX] 00:00
    ><fs> list-filesystems

doc/source/operations/control-plane-operation.rst

@@ -55,7 +55,7 @@ Configuring Prometheus Alerts
 -----------------------------
 
 Alerts are defined in code and stored in Kayobe configuration. See ``*.rules``
-files in ``${KAYOBE_CONFIG_PATH}/kolla/config/prometheus`` as a model to add
+files in ``$KAYOBE_CONFIG_PATH/kolla/config/prometheus`` as a model to add
 custom rules.
 
 Silencing Prometheus Alerts
@@ -88,7 +88,7 @@ Generating Alerts from Metrics
 ++++++++++++++++++++++++++++++
 
 Alerts are defined in code and stored in Kayobe configuration. See ``*.rules``
-files in ``${KAYOBE_CONFIG_PATH}/kolla/config/prometheus`` as a model to add
+files in ``$KAYOBE_CONFIG_PATH/kolla/config/prometheus`` as a model to add
 custom rules.
 
 Control Plane Shutdown Procedure
@@ -124,7 +124,7 @@ The password can be found using:
 
 .. code-block:: console
 
-   kayobe# ansible-vault view ${KAYOBE_CONFIG_PATH}/kolla/passwords.yml \
+   kayobe# ansible-vault view $KAYOBE_CONFIG_PATH/kolla/passwords.yml \
            --vault-password-file <Vault password file path> | grep ^database
 
 Checking RabbitMQ
@@ -135,6 +135,7 @@ RabbitMQ health is determined using the command ``rabbitmqctl cluster_status``:
 .. code-block:: console
 
    [stack@controller0 ~]$ docker exec rabbitmq rabbitmqctl cluster_status
+
    Cluster status of node rabbit@controller0 ...
    [{nodes,[{disc,['rabbit@controller0','rabbit@controller1',
                    'rabbit@controller2']}]},
@@ -180,20 +181,18 @@ If you are shutting down a single hypervisor, to avoid down time to tenants it
 is advisable to migrate all of the instances to another machine. See
 :ref:`evacuating-all-instances`.
 
-.. ifconfig:: deployment['ceph_managed']
-
-   Ceph
-   ----
+Ceph
+----
 
-   The following guide provides a good overview:
-   https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/8/html/director_installation_and_usage/sect-rebooting-ceph
+The following guide provides a good overview:
+https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/8/html/director_installation_and_usage/sect-rebooting-ceph
 
 Shutting down the seed VM
 -------------------------
 
 .. code-block:: console
 
-   kayobe# virsh shutdown <Seed node>
+   kayobe# virsh shutdown <Seed hostname>
 
 .. _full-shutdown:
 
@@ -262,7 +261,7 @@ hypervisor is powered on. If it does not, it can be started with:
 
 .. code-block:: console
 
-   kayobe# virsh start seed-0
+   kayobe# virsh start <Seed hostname>
 
 Full power on
 -------------
@@ -340,13 +339,14 @@ To see the list of hypervisor names:
 
 .. code-block:: console
 
-   admin# openstack hypervisor list
+   # From host that can reach Openstack
+   openstack hypervisor list
 
 To boot an instance on a specific hypervisor
 
 .. code-block:: console
 
-   admin# openstack server create --flavor <Flavour name>--network <Network name> --key-name <key> --image <Image name> --availability-zone nova::<Hypervisor name> <VM name>
+   openstack server create --flavor <Flavour name>--network <Network name> --key-name <key> --image <Image name> --availability-zone nova::<Hypervisor name> <VM name>
 
 Cleanup Procedures
 ==================
@@ -360,22 +360,23 @@ perform the following cleanup procedure regularly:
 
 .. code-block:: console
 
-   admin# for user in $(openstack user list --domain magnum -f value -c Name | grep -v magnum_trustee_domain_admin); do
-            if openstack coe cluster list -c uuid -f value | grep -q $(echo $user | sed 's/_[0-9a-f]*$//'); then
-              echo "$user still in use, not deleting"
-            else
-              openstack user delete --domain magnum $user
-            fi
-          done
+   for user in $(openstack user list --domain magnum -f value -c Name | grep -v magnum_trustee_domain_admin); do
+      if openstack coe cluster list -c uuid -f value | grep -q $(echo $user | sed 's/_[0-9a-f]*$//'); then
+         echo "$user still in use, not deleting"
+      else
+         openstack user delete --domain magnum $user
+      fi
+      done
 
 OpenSearch indexes retention
 =============================
 
 To alter default rotation values for OpenSearch, edit
 
-``${KAYOBE_CONFIG_PATH}/kolla/globals.yml``:
+``$KAYOBE_CONFIG_PATH/kolla/globals.yml``:
 
 .. code-block:: console
+
    # Duration after which index is closed (default 30)
    opensearch_soft_retention_period_days: 90
    # Duration after which index is deleted (default 60)
@@ -384,8 +385,8 @@ To alter default rotation values for OpenSearch, edit
 Reconfigure Opensearch with new values:
 
 .. code-block:: console
-   kayobe overcloud service reconfigure --kolla-tags opensearch
 
-For more information see the `upstream documentation
+   kayobe# kayobe overcloud service reconfigure --kolla-tags opensearch
 
+For more information see the `upstream documentation
 <https://docs.openstack.org/kolla-ansible/latest/reference/logging-and-monitoring/central-logging-guide.html#applying-log-retention-policies>`__.

…ource/operations/customising_horizon.rst …ource/operations/customising-horizon.rstdoc/source/operations/customising_horizon.rst renamed to doc/source/operations/customising-horizon.rst doc/source/operations/customising_horizon.rst renamed to doc/source/operations/customising-horizon.rst

@@ -1,8 +1,6 @@
-.. include:: vars.rst
-
-====================================
+===================
 Customising Horizon
-====================================
+===================
 
 Horizon is the most frequent site-specific container customisation required:
 other customisations tend to be common across deployments, but personalisation
@@ -55,7 +53,6 @@ Building a custom container image for Horizon can be done by modifying
 ``kolla.yml`` to fetch the custom theme and include it in the image:
 
 .. code-block:: yaml
-   :substitutions:
 
    kolla_sources:
      horizon-additions-theme-<custom theme name>:

doc/source/operations/hardware-inventory-management.rst

@@ -5,7 +5,7 @@ Hardware Inventory Management
 At its lowest level, hardware inventory is managed in the Bifrost service.
 
 Reconfiguring Control Plane Hardware
-------------------------------------
+====================================
 
 If a server's hardware or firmware configuration is changed, it should be
 re-inspected in Bifrost before it is redeployed into service. A single server
@@ -112,10 +112,10 @@ hypervisor. They should all show the status ACTIVE. This can be verified with:
    admin# openstack server show <instance uuid>
 
 Troubleshooting
-+++++++++++++++
+===============
 
 Servers that have been shut down
-********************************
+--------------------------------
 
 If there are any instances that are SHUTOFF they won’t be migrated, but you can
 use ``openstack server migrate`` for them once the live migration is finished.
@@ -131,7 +131,7 @@ For more details see:
 http://www.danplanet.com/blog/2016/03/03/evacuate-in-nova-one-command-to-confuse-us-all/
 
 Flavors have changed
-********************
+--------------------
 
 If the size of the flavors has changed, some instances will also fail to
 migrate as the process needs manual confirmation. You can do this with:
@@ -150,7 +150,7 @@ RESIZE`` as shown in this snippet of ``openstack server show <instance-uuid>``:
 .. _set-bifrost-maintenance-mode:
 
 Set maintenance mode on a node in Bifrost
-+++++++++++++++++++++++++++++++++++++++++
+-----------------------------------------
 
 .. code-block:: console
 
@@ -161,7 +161,7 @@ Set maintenance mode on a node in Bifrost
 .. _unset-bifrost-maintenance-mode:
 
 Unset maintenance mode on a node in Bifrost
-+++++++++++++++++++++++++++++++++++++++++++
+-------------------------------------------
 
 .. code-block:: console
 

doc/source/operations/index.rst

@@ -7,10 +7,20 @@ This guide is for operators of the StackHPC Kayobe configuration project.
 .. toctree::
    :maxdepth: 1
 
+   baremetal-node-management
+   ceph-management
+   control-plane-operation
+   customsing-horizon
+   gpu-in-openstack
+   hardware-inventory-management
    hotfix-playbook
+   migrating-vm
    nova-compute-ironic
    octavia
+   openstack-projects-and-users-management
+   openstack-reconfiguration
    rabbitmq
    secret-rotation
    tempest
    upgrading
+   wazuh-operation