Replace etc/kayobe to $KAYOBE_CONFIG_PATH

seunghun1ee · seunghun1ee · commit c444bf0c6e00 · 2024-10-09T12:11:54.000+01:00
diff --git a/doc/source/operations/ceph-management.rst b/doc/source/operations/ceph-management.rst
@@ -11,9 +11,9 @@ please refer to :ref:`cephadm-kayobe` documentation.
 Cephadm configuration location
 ------------------------------
 
-In kayobe-config repository, under ``etc/kayobe/cephadm.yml`` (or in a specific
+In kayobe-config repository, under ``$KAYOBE_CONFIG_PATH/cephadm.yml`` (or in a specific
 Kayobe environment when using multiple environment, e.g.
-``etc/kayobe/environments/<Environment Name>/cephadm.yml``)
+``$KAYOBE_CONFIG_PATH/environments/<environment name>/cephadm.yml``)
 
 StackHPC's Cephadm Ansible collection relies on multiple inventory groups:
 
@@ -22,12 +22,12 @@ StackHPC's Cephadm Ansible collection relies on multiple inventory groups:
 - ``osds``
 - ``rgws`` (optional)
 
-Those groups are usually defined in ``etc/kayobe/inventory/groups``.
+Those groups are usually defined in ``$KAYOBE_CONFIG_PATH/inventory/groups``.
 
 Running Cephadm playbooks
 -------------------------
 
-In kayobe-config repository, under ``etc/kayobe/ansible`` there is a set of
+In kayobe-config repository, under ``$KAYOBE_CONFIG_PATH/ansible`` there is a set of
 Cephadm based playbooks utilising stackhpc.cephadm Ansible Galaxy collection.
 
 ``cephadm.yml`` runs the end to end process of Cephadm deployment and
@@ -38,14 +38,14 @@ and they can be run separately.
   additional playbooks
 - ``cephadm-commands-pre.yml`` - Runs Ceph commands before post-deployment
   configuration (You can set a list of commands at ``cephadm_commands_pre_extra``
-  in ``cephadm.yml``)
+  variable in ``$KAYOBE_CONFIG_PATH/cephadm.yml``)
 - ``cephadm-ec-profiles.yml`` - Defines Ceph EC profiles
 - ``cephadm-crush-rules.yml`` - Defines Ceph crush rules according
 - ``cephadm-pools.yml`` - Defines Ceph pools
 - ``cephadm-keys.yml`` - Defines Ceph users/keys
 - ``cephadm-commands-post.yml`` - Runs Ceph commands after post-deployment
   configuration (You can set a list of commands at ``cephadm_commands_post_extra``
-  in ``cephadm.yml``)
+  variable in ``$KAYOBE_CONFIG_PATH/cephadm.yml``)
 
 There are also other Ceph playbooks that are not part of ``cephadm.yml``
 
@@ -102,7 +102,7 @@ Once all daemons are removed - you can remove the host:
    ceph orch host rm <host>
 
 And then remove the host from inventory (usually in
-``etc/kayobe/inventory/overcloud``)
+``$KAYOBE_CONFIG_PATH/inventory/overcloud``)
 
 Additional options/commands may be found in
 `Host management <https://docs.ceph.com/en/latest/cephadm/host-management/>`_
@@ -194,7 +194,7 @@ 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
 they match an existing drivegroup spec.
 If this is not your desired action plan - it's best to modify the drivegroup
-spec before (``cephadm_osd_spec`` variable in ``etc/kayobe/cephadm.yml``).
+spec before (``cephadm_osd_spec`` variable in ``$KAYOBE_CONFIG_PATH/cephadm.yml``).
 Either set ``unmanaged: true`` to stop Cephadm from picking up new disks or
 modify it in some way that it no longer matches the drives you want to remove.
 
diff --git a/doc/source/operations/customising-horizon.rst b/doc/source/operations/customising-horizon.rst
@@ -51,7 +51,7 @@ Adding the custom theme
 
 Create a directory and transfer custom theme files to it ``$KAYOBE_CONFIG_PATH/kolla/config/horizon/themes/<custom theme name>``.
 
-Define the custom theme in ``etc/kayobe/kolla/globals.yml``
+Define the custom theme in ``$KAYOBE_CONFIG_PATH/kolla/globals.yml``
 
 .. code-block:: yaml
 
diff --git a/doc/source/operations/gpu-in-openstack.rst b/doc/source/operations/gpu-in-openstack.rst
@@ -991,7 +991,7 @@ Configure nova-scheduler
 
 The nova-scheduler service must be configured to enable the ``PciPassthroughFilter``
 To enable it add it to the list of filters to Kolla-Ansible configuration file:
-``etc/kayobe/kolla/config/nova.conf``, for instance:
+``$KAYOBE_CONFIG_PATH/kolla/config/nova.conf``, for instance:
 
 .. code-block:: yaml
 
@@ -1006,7 +1006,7 @@ Configuration can be applied in flexible ways using Kolla-Ansible's
 methods for `inventory-driven customisation of configuration
 <https://docs.openstack.org/kayobe/latest/configuration/reference/kolla-ansible.html#service-configuration>`_.
 The following configuration could be added to
-``etc/kayobe/kolla/config/nova/nova-compute.conf`` to enable PCI
+``$KAYOBE_CONFIG_PATH/kolla/config/nova/nova-compute.conf`` to enable PCI
 passthrough of GPU devices for hosts in a group named ``compute_gpu``.
 Again, the 4-digit PCI Vendor ID and Device ID extracted from ``lspci
 -nn`` can be used here to specify the GPU device(s).
@@ -1037,7 +1037,7 @@ Configure nova-api
 pci.alias also needs to be configured on the controller.
 This configuration should match the configuration found on the compute nodes.
 Add it to Kolla-Ansible configuration file:
-``etc/kayobe/kolla/config/nova/nova-api.conf``, for instance:
+``$KAYOBE_CONFIG_PATH/kolla/config/nova/nova-api.conf``, for instance:
 
 .. code-block:: yaml
 
diff --git a/doc/source/operations/nova-compute-ironic.rst b/doc/source/operations/nova-compute-ironic.rst
@@ -68,7 +68,7 @@ Moving from multiple Nova Compute Instances to a single instance
 1. Decide where the single instance should run. This should normally be
    one of the three OpenStack control plane hosts. For convention, pick
    the first one, unless you can think of a good reason not to. Once you
-   have chosen, set the following variable in ``etc/kayobe/nova.yml``.
+   have chosen, set the following variable in ``$KAYOBE_CONFIG_PATH/nova.yml``.
    Here we have picked ``controller1``.
 
   .. code-block:: yaml
@@ -196,7 +196,7 @@ constant, such that the new Nova Compute Ironic instance comes up with the
 same name as the one it replaces.
 
 For example, if the original instance resides on ``controller1``, then set the
-following in ``etc/kayobe/nova.yml``:
+following in ``$KAYOBE_CONFIG_PATH/nova.yml``:
 
 .. code-block:: yaml
 
@@ -270,8 +270,8 @@ Current host is not accessible
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 In this case you will need to remove the inaccessible host from the inventory.
-For example, in ``etc/kayobe/inventory/hosts``, remove ``controller1`` from
-the ``controllers`` group.
+For example, in ``$KAYOBE_CONFIG_PATH/inventory/hosts``, remove ``controller1``
+from the ``controllers`` group.
 
 Adjust the ``kolla_nova_compute_ironic_host`` variable to point to the
 new host, eg.
diff --git a/doc/source/operations/openstack-reconfiguration.rst b/doc/source/operations/openstack-reconfiguration.rst
@@ -73,7 +73,7 @@ Alternative Configuration
 
 As an alternative to writing the certificates as a variable to
 ``secrets.yml``, it is also possible to write the same data to a file,
-``etc/kayobe/kolla/certificates/haproxy.pem``.  The file should be
+``$KAYOBE_CONFIG_PATH/kolla/certificates/haproxy.pem``.  The file should be
 vault-encrypted in the same manner as secrets.yml.  In this instance,
 variable ``kolla_external_tls_cert`` does not need to be defined.
 
diff --git a/doc/source/operations/secret-rotation.rst b/doc/source/operations/secret-rotation.rst
@@ -105,7 +105,7 @@ Full method
 
 3. Navigate to the directory containing your ``passwords.yml`` file
    (``kayobe-config/etc/kolla/passwords.yml`` OR
-   ``kayobe-config/etc/kayobe/environments/envname/kolla/passwords.yml``)
+   ``kayobe-config/etc/kayobe/environments/<envname>/kolla/passwords.yml``)
 
 4. Create a file called ``deletelist.txt`` and populate it with this content
    (including all whitespace):
