Replace etc/kayobe to $KAYOBE_CONFIG_PATH

Author: seunghun1ee

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.
 

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
 

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
 

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.

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.
 

doc/source/operations/secret-rotation.rst

@@ -74,7 +74,7 @@ Full method
    the state of the cloud before any changes are made
 
 2. Edit your Kolla-Ansible checkout to include changes not yet included
-   upstream. 
+   upstream.
 
 .. _kolla-change:
 
@@ -98,14 +98,14 @@ Full method
       .. code:: bash
 
          git fetch https://review.opendev.org/openstack/kolla-ansible refs/changes/78/903178/2 && git cherry-pick FETCH_HEAD
-   
+
    3. Re-install Kolla-Ansible from source in your Kolla-Ansible Python
       environment
 
 
 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):
@@ -129,7 +129,7 @@ Full method
       ^redis_master_password
       ^memcache_secret_key
       _ssh_key
-         
+
          private_key
          public_key
       ^$