Remove command prefixes

seunghun1ee · seunghun1ee · commit 869fb57696ef · 2024-12-05T11:39:56.000Z
diff --git a/doc/source/operations/bifrost-hardware-inventory-management.rst b/doc/source/operations/bifrost-hardware-inventory-management.rst
@@ -13,7 +13,7 @@ can be reinspected like this:
 
 .. code-block:: console
 
-   kayobe# kayobe overcloud hardware inspect --limit <Host name>
+   kayobe overcloud hardware inspect --limit <Host name>
 
 .. _enrolling-new-hypervisors:
 
@@ -30,26 +30,26 @@ file located at ``$KAYOBE_CONFIG_PATH/secrets.yml``.
 
 .. code-block:: console
 
-   bifrost# ipmitool -I lanplus -U <ipmi username> -H <Hostname>-ipmi chassis bootdev pxe
+   ipmitool -I lanplus -U <ipmi username> -H <Hostname>-ipmi chassis bootdev pxe
 
 If node is are off, power them on:
 
 .. code-block:: console
 
-   bifrost# ipmitool -I lanplus -U <ipmi username> -H <Hostname>-ipmi power on
+   ipmitool -I lanplus -U <ipmi username> -H <Hostname>-ipmi power on
 
 If nodes is on, reset them:
 
 .. code-block:: console
 
-   bifrost# ipmitool -I lanplus -U <ipmi username> -H <Hostname>-ipmi power reset
+   ipmitool -I lanplus -U <ipmi username> -H <Hostname>-ipmi power reset
 
 Once node have booted and have completed introspection, they should be visible
 in Bifrost:
 
 .. code-block:: console
 
-   bifrost# baremetal node list --provision-state enroll
+   baremetal node list --provision-state enroll
    +--------------------------------------+-----------------------+---------------+-------------+--------------------+-------------+
    | UUID                                 | Name                  | Instance UUID | Power State | Provisioning State | Maintenance |
    +--------------------------------------+-----------------------+---------------+-------------+--------------------+-------------+
@@ -63,15 +63,15 @@ the correct groups, import them in Kayobe's inventory with:
 
 .. code-block:: console
 
-   kayobe# kayobe overcloud inventory discover
+   kayobe overcloud inventory discover
 
 We can then provision and configure them:
 
 .. code-block:: console
 
-   kayobe# kayobe overcloud provision --limit <Hostname>
-   kayobe# kayobe overcloud host configure --limit <Hostname>
-   kayobe# kayobe overcloud service deploy --limit <Hostname> --kolla-limit <Hostname>
+   kayobe overcloud provision --limit <Hostname>
+   kayobe overcloud host configure --limit <Hostname>
+   kayobe overcloud service deploy --limit <Hostname> --kolla-limit <Hostname>
 
 .. note::
 
@@ -94,7 +94,7 @@ To deprovision an existing hypervisor, run:
 
 .. code-block:: console
 
-   kayobe# kayobe overcloud deprovision --limit <Hypervisor hostname>
+   kayobe overcloud deprovision --limit <Hypervisor hostname>
 
 .. warning::
 
@@ -109,14 +109,14 @@ Evacuating all instances
 
 .. code-block:: console
 
-   admin# openstack server evacuate $(openstack server list --host <Hypervisor hostname> --format value --column ID)
+   openstack server evacuate $(openstack server list --host <Hypervisor hostname> --format value --column ID)
 
 You should now check the status of all the instances that were running on that
 hypervisor. They should all show the status ACTIVE. This can be verified with:
 
 .. code-block:: console
 
-   admin# openstack server show <instance uuid>
+   openstack server show <instance uuid>
 
 Troubleshooting
 ===============
@@ -145,7 +145,7 @@ migrate as the process needs manual confirmation. You can do this with:
 
 .. code-block:: console
 
-   openstack# openstack server resize confirm <instance-uuid>
+   openstack server resize confirm <instance-uuid>
 
 The symptom to look out for is that the server is showing a status of ``VERIFY
 RESIZE`` as shown in this snippet of ``openstack server show <instance-uuid>``:
@@ -161,7 +161,7 @@ Set maintenance mode on a node in Bifrost
 
 .. code-block:: console
 
-   seed# docker exec -it bifrost_deploy /bin/bash
+   docker exec -it bifrost_deploy /bin/bash
    (bifrost-deploy)[root@seed bifrost-base]# export OS_CLOUD=bifrost
    (bifrost-deploy)[root@seed bifrost-base]# baremetal node maintenance set <Hostname>
 
@@ -172,7 +172,7 @@ Unset maintenance mode on a node in Bifrost
 
 .. code-block:: console
 
-   seed# docker exec -it bifrost_deploy /bin/bash
+   docker exec -it bifrost_deploy /bin/bash
    (bifrost-deploy)[root@seed bifrost-base]# export OS_CLOUD=bifrost
    (bifrost-deploy)[root@seed bifrost-base]# baremetal node maintenance unset <Hostname>
 
@@ -210,7 +210,7 @@ into ``$KAYOBE_CONFIG_PATH/overcloud-introspection-data``:
 
 .. code-block:: console
 
-   kayobe# kayobe overcloud introspection data save
+   kayobe overcloud introspection data save
 
 Using ADVise
 ------------
diff --git a/doc/source/operations/control-plane-operation.rst b/doc/source/operations/control-plane-operation.rst
@@ -120,7 +120,7 @@ The password can be found using:
 
 .. code-block:: console
 
-   kayobe# ansible-vault view $KAYOBE_CONFIG_PATH/kolla/passwords.yml \
+   ansible-vault view $KAYOBE_CONFIG_PATH/kolla/passwords.yml \
            --vault-password-file <Vault password file path> | grep ^database
 
 Checking RabbitMQ
@@ -188,7 +188,7 @@ Shutting down the seed VM
 
 .. code-block:: console
 
-   kayobe# virsh shutdown <Seed hostname>
+   virsh shutdown <Seed hostname>
 
 .. _full-shutdown:
 
@@ -215,7 +215,7 @@ Example: Reboot all compute hosts apart from compute0:
 
 .. code-block:: console
 
-   kayobe# kayobe playbook run $KAYOBE_CONFIG_PATH/ansible/reboot.yml --limit 'compute:!compute0'
+   kayobe playbook run $KAYOBE_CONFIG_PATH/ansible/reboot.yml --limit 'compute:!compute0'
 
 References
 ----------
@@ -242,7 +242,7 @@ with the following command:
 
 .. code-block:: console
 
-   kayobe# kayobe overcloud database recover
+   kayobe overcloud database recover
 
 Ansible Control Host
 --------------------
@@ -258,7 +258,7 @@ hypervisor is powered on. If it does not, it can be started with:
 
 .. code-block:: console
 
-   kayobe# virsh start <Seed hostname>
+   virsh start <Seed hostname>
 
 Full power on
 -------------
@@ -275,7 +275,7 @@ Log into the monitoring host(s):
 
 .. code-block:: console
 
-   kayobe# ssh stack@monitoring0
+   ssh stack@monitoring0
 
 Stop all Docker containers:
 
@@ -312,22 +312,22 @@ To sync host packages:
 
 .. code-block:: console
 
-   kayobe# kayobe playbook run $KAYOBE_CONFIG_PATH/ansible/pulp-repo-sync.yml
-   kayobe# kayobe playbook run $KAYOBE_CONFIG_PATH/ansible/pulp-repo-publish.yml
+   kayobe playbook run $KAYOBE_CONFIG_PATH/ansible/pulp-repo-sync.yml
+   kayobe playbook run $KAYOBE_CONFIG_PATH/ansible/pulp-repo-publish.yml
 
 If the system is production environment and want to use packages tested in test/staging
 environment, you can promote them by:
 
 .. code-block:: console
 
-   kayobe# kayobe playbook run $KAYOBE_CONFIG_PATH/ansible/pulp-repo-promote-production.yml
+   kayobe playbook run $KAYOBE_CONFIG_PATH/ansible/pulp-repo-promote-production.yml
 
 To sync container images:
 
 .. code-block:: console
 
-   kayobe# kayobe playbook run $KAYOBE_CONFIG_PATH/ansible/pulp-container-sync.yml
-   kayobe# kayobe playbook run $KAYOBE_CONFIG_PATH/ansible/pulp-container-publish.yml
+   kayobe playbook run $KAYOBE_CONFIG_PATH/ansible/pulp-container-sync.yml
+   kayobe playbook run $KAYOBE_CONFIG_PATH/ansible/pulp-container-publish.yml
 
 For more information about StackHPC Release Train, see :ref:`stackhpc-release-train` documentation.
 
@@ -341,8 +341,8 @@ Host packages can be updated with:
 
 .. code-block:: console
 
-   kayobe# kayobe overcloud host package update --limit <node> --packages '*'
-   kayobe# kayobe seed host package update --packages '*'
+   kayobe overcloud host package update --limit <node> --packages '*'
+   kayobe seed host package update --packages '*'
 
 See https://docs.openstack.org/kayobe/latest/administration/overcloud.html#updating-packages
 
@@ -387,7 +387,7 @@ Reconfigure Opensearch with new values:
 
 .. code-block:: console
 
-   kayobe# kayobe overcloud service reconfigure --kolla-tags opensearch
+   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>`__.
diff --git a/doc/source/operations/gpu-in-openstack.rst b/doc/source/operations/gpu-in-openstack.rst
@@ -783,8 +783,8 @@ add extra_specs to flavor in etc/openstack-config/openstack-config.yml:
 
 .. code-block:: console
 
-   admin# cd src/openstack-config
-   admin# vim etc/openstack-config/openstack-config.yml
+   cd src/openstack-config
+   vim etc/openstack-config/openstack-config.yml
 
     name: "m1.medium-gpu"
     ram: 4096
@@ -797,9 +797,9 @@ Invoke configuration playbooks afterwards:
 
 .. code-block:: console
 
-   admin# source src/kayobe-config/etc/kolla/public-openrc.sh
-   admin# source venvs/openstack/bin/activate
-   admin# tools/openstack-config --vault-password-file <Vault password file path>
+   source src/kayobe-config/etc/kolla/public-openrc.sh
+   source venvs/openstack/bin/activate
+   tools/openstack-config --vault-password-file <Vault password file path>
 
 Create instance with GPU passthrough
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
diff --git a/doc/source/operations/migrating-vm.rst b/doc/source/operations/migrating-vm.rst
@@ -6,17 +6,17 @@ To see where all virtual machines are running on the hypervisors:
 
 .. code-block:: console
 
-   admin# openstack server list --all-projects --long
+   openstack server list --all-projects --long
 
 To move a virtual machine with shared storage or booted from volume from one hypervisor to another, for example to
 hypervisor-01:
 
 .. code-block:: console
 
-   admin# openstack server migrate --live-migration --host hypervisor-01 <VM name or uuid>
+   openstack server migrate --live-migration --host hypervisor-01 <VM name or uuid>
 
 To move a virtual machine with local disks:
 
 .. code-block:: console
 
-   admin# openstack server migrate --live-migration --block-migration --host hypervisor-01 <VM name or uuid>
+   openstack server migrate --live-migration --block-migration --host hypervisor-01 <VM name or uuid>
diff --git a/doc/source/operations/openstack-reconfiguration.rst b/doc/source/operations/openstack-reconfiguration.rst
@@ -21,7 +21,7 @@ Then, reconfigure Cinder services with Kayobe:
 
 .. code-block:: console
 
-   kayobe# kayobe overcloud service reconfigure --kolla-tags cinder
+   kayobe overcloud service reconfigure --kolla-tags cinder
 
 However, the service itself, no longer in Ansible's manifest of managed state,
 must be manually stopped and prevented from restarting.
@@ -30,7 +30,7 @@ On each controller:
 
 .. code-block:: console
 
-   kayobe# docker rm -f cinder_backup
+   docker rm -f cinder_backup
 
 Some services may store data in a dedicated Docker volume, which can be removed
 with ``docker volume rm``.
@@ -50,7 +50,7 @@ Use a command of this form:
 
 .. code-block:: console
 
-   kayobe# ansible-vault edit $KAYOBE_CONFIG_PATH/secrets.yml --vault-password-file=<Vault password file path>
+   ansible-vault edit $KAYOBE_CONFIG_PATH/secrets.yml --vault-password-file=<Vault password file path>
 
 Concatenate the contents of the certificate and key files to create
 ``secrets_kolla_external_tls_cert``.  The certificates should be installed in
@@ -72,7 +72,7 @@ be updated in Keystone:
 
 .. code-block:: console
 
-   kayobe# kayobe overcloud service reconfigure
+   kayobe overcloud service reconfigure
 
 Alternative Configuration
 -------------------------
@@ -95,7 +95,7 @@ reach the OpenStack APIs:
 
 .. code-block:: console
 
-   openstack# openssl s_client -connect <Public endpoint FQDN>:443 2> /dev/null | openssl x509 -noout -dates
+   openssl s_client -connect <Public endpoint FQDN>:443 2> /dev/null | openssl x509 -noout -dates
 
 .. note::
 
@@ -108,7 +108,7 @@ above. Run the following command:
 
 .. code-block:: console
 
-   kayobe# kayobe overcloud service reconfigure --kolla-tags haproxy
+   kayobe overcloud service reconfigure --kolla-tags haproxy
 
 .. _taking-a-hypervisor-out-of-service:
 
@@ -119,8 +119,7 @@ To take a hypervisor out of Nova scheduling:
 
 .. code-block:: console
 
-   admin# openstack compute service set --disable \
-          <Hypervisor name> nova-compute
+   openstack compute service set --disable <Hypervisor name> nova-compute
 
 Running instances on the hypervisor will not be affected, but new instances
 will not be deployed on it.
@@ -130,19 +129,18 @@ A reason for disabling a hypervisor can be documented with the
 
 .. code-block:: console
 
-   admin# openstack compute service set --disable \
-          --disable-reason "Broken drive" <Hypervisor name> nova-compute
+   openstack compute service set --disable \
+   --disable-reason "Broken drive" <Hypervisor name> nova-compute
 
 Details about all hypervisors and the reasons they are disabled can be
 displayed with:
 
 .. code-block:: console
 
-   admin# openstack compute service list --long
+   openstack compute service list --long
 
 And then to enable a hypervisor again:
 
 .. code-block:: console
 
-   admin# openstack compute service set --enable \
-          <Hypervisor name> nova-compute
+   openstack compute service set --enable <Hypervisor name> nova-compute
