diff --git a/source/baremetal_management.rst b/source/baremetal_management.rst index d958ba6..50ab80b 100644 --- a/source/baremetal_management.rst +++ b/source/baremetal_management.rst @@ -216,3 +216,7 @@ Considerations when booting baremetal compared to VMs - Instances take much longer to provision (expect at least 15 mins) - When booting an instance use one of the flavors that maps to a baremetal node via the RESOURCE_CLASS configured on the flavor. + +.. ifconfig:: deployment['ironic_hypervisor_conversion'] + + .. include:: baremetal_management_ironic_conversion.rst diff --git a/source/baremetal_management_ironic_burn_in.rst b/source/baremetal_management_ironic_burn_in.rst new file mode 100644 index 0000000..9a4c57e --- /dev/null +++ b/source/baremetal_management_ironic_burn_in.rst @@ -0,0 +1,288 @@ +.. include:: vars.rst + +============================== +Ironic Node Burn-in +============================== + +Workflows to onboard new hardware often include a stress-testing step to +provoke early failures, so that load-triggered issues do not only occur +once the node has already moved to production. These `burn-in` tests +typically cover the CPU, memory, disk and network (and GPUs where +present). + +Ironic supports such tests as part of its cleaning framework: each test +runs as a cleaning step inside the Ironic Python Agent (IPA) ramdisk, +using standard tools: + +- `stress-ng `__ for CPU and memory +- `fio `__ for disk and network +- `gpu-burn `__ for GPU tests + +Because the burn-in steps are part of the generic hardware manager in the +IPA, they are available without bundling a specific IPA hardware manager +into the ramdisk. + +.. note:: + + The |project_name| IPA image is built from source with the ``burn-in`` + DIB element (see ``ipa_build_dib_elements_extra`` in + ``etc/kayobe/ipa.yml`` in the |kayobe_config| repository), so the burn-in + tools are already present in the agent ramdisk. No IPA image rebuild is + required before running the tests. + +Running a burn-in test +---------------------- + +Burn-in steps are launched with ``baremetal node clean`` using an explicit +``--clean-steps`` argument that overrides the default cleaning steps. Each +test is configured with driver-info options on the node, all prefixed with +``agent_burnin_``. + +Before starting, the node must be in the ``manageable`` or ``available`` +provision state (see :ref:`ironic-node-lifecycle`). Run the commands below +as an administrator with OpenStack admin credentials loaded (see +:doc:`introduction` for the prompt conventions). + +The examples use ``cloudcomp100`` as the node under test; substitute the +hostname or UUID of the node being burned in. + +CPU burn-in +^^^^^^^^^^^ + +Available options (following the ``agent_burnin_`` + stress-ng stressor +(``cpu``) + stress-ng option schema): + +- ``agent_burnin_cpu_timeout`` (default: 24 hours) +- ``agent_burnin_cpu_cpu`` (default: 0, meaning all CPUs) + +to limit the overall runtime and to pick the number of CPUs to stress. + +For instance, to limit the CPU burn-in on ``cloudcomp100`` to 10 minutes: + +.. code-block:: console + + admin# openstack baremetal node set \ + --driver-info agent_burnin_cpu_timeout=600 cloudcomp100 + +Then launch the test: + +.. code-block:: console + + admin# openstack baremetal node clean \ + --clean-steps '[{"step": "burnin_cpu", "interface": "deploy"}]' \ + cloudcomp100 + +Memory burn-in +^^^^^^^^^^^^^^ + +Available options (following the ``agent_burnin_`` + stress-ng stressor +(``vm``) + stress-ng option schema): + +- ``agent_burnin_vm_timeout`` (default: 24 hours) +- ``agent_burnin_vm_vm-bytes`` (default: 98%) + +to limit the overall runtime and to set the fraction of RAM to stress. + +For instance, to limit the memory burn-in to 1 hour and the amount of RAM +to be used to 75%: + +.. code-block:: console + + admin# openstack baremetal node set \ + --driver-info agent_burnin_vm_timeout=3600 cloudcomp100 + admin# openstack baremetal node set \ + --driver-info agent_burnin_vm_vm-bytes=75% cloudcomp100 + +Then launch the test: + +.. code-block:: console + + admin# openstack baremetal node clean \ + --clean-steps '[{"step": "burnin_memory", "interface": "deploy"}]' \ + cloudcomp100 + +Disk burn-in +^^^^^^^^^^^^ + +Available options (following the ``agent_burnin_`` + fio stressor +(``fio_disk``) + fio option schema): + +- ``agent_burnin_fio_disk_runtime`` (default: 0, meaning no time limit) +- ``agent_burnin_fio_disk_loops`` (default: 4) + +to set the time limit and the number of iterations when going over the +disks. + +For instance, to limit the number of loops to 2: + +.. code-block:: console + + admin# openstack baremetal node set \ + --driver-info agent_burnin_fio_disk_loops=2 cloudcomp100 + +To launch a parallel SMART self-test on all devices after the disk burn-in +(which will fail the step if any of the tests fail), also set: + +.. code-block:: console + + admin# openstack baremetal node set \ + --driver-info agent_burnin_fio_disk_smart_test=True cloudcomp100 + +Then launch the test: + +.. code-block:: console + + admin# openstack baremetal node clean \ + --clean-steps '[{"step": "burnin_disk", "interface": "deploy"}]' \ + cloudcomp100 + +Network burn-in +^^^^^^^^^^^^^^^ + +The network test needs a pair of nodes, one acting as ``writer`` and the +other as ``reader``. The pairing can be defined either statically, i.e. +pairs are defined upfront, or dynamically via a distributed coordination +backend which orchestrates the pair matching. The static approach is more +predictable in terms of which nodes test each other; the dynamic approach +avoids nodes being blocked if one of the pair has problems, by simply +pairing all available nodes. + +The |project_name| deployment does not run a coordination backend (such as +ZooKeeper), so network burn-in pairs are defined **statically**: + +.. code-block:: console + + admin# openstack baremetal node set \ + --driver-info agent_burnin_fio_network_config='{"role": "writer", "partner": "cloudcomp101"}' \ + cloudcomp100 + admin# openstack baremetal node set \ + --driver-info agent_burnin_fio_network_config='{"role": "reader", "partner": "cloudcomp100"}' \ + cloudcomp101 + +The test also has a runtime option, which only needs to be set on the +writer: + +.. code-block:: console + + admin# openstack baremetal node set \ + --driver-info agent_burnin_fio_network_runtime=600 cloudcomp100 + +The network burn-in is launched on **both** nodes of the pair: + +.. code-block:: console + + admin# openstack baremetal node clean \ + --clean-steps '[{"step": "burnin_network", "interface": "deploy"}]' \ + cloudcomp100 + admin# openstack baremetal node clean \ + --clean-steps '[{"step": "burnin_network", "interface": "deploy"}]' \ + cloudcomp101 + +Both nodes wait for the other node to show up and block while waiting. If +the partner does not show up, the cleaning timeout will step in. + +GPU burn-in +^^^^^^^^^^^ + +The GPU burn-in tests come in two parts: + +- Check that the correct number of GPUs are visible to the operating + system (only performed if ``agent_burnin_gpu_count`` is set to a value + above 0) +- GPU burn-in test using gpu-burn + +Available options (following the ``agent_burnin_`` + gpu stressor +(``gpu``) option schema): + +- ``agent_burnin_gpu_install_dir`` (default: /opt/gpu-burn) +- ``agent_burnin_gpu_timeout`` (default: 24 hours) +- ``agent_burnin_gpu_memory`` (default: 95%) +- ``agent_burnin_gpu_count`` (default: 0, the GPU count check is disabled) + +For instance, to limit the GPU burn-in to 10 minutes: + +.. code-block:: console + + admin# openstack baremetal node set \ + --driver-info agent_burnin_gpu_timeout=600 cloudcomp100 + +Then launch the test: + +.. code-block:: console + + admin# openstack baremetal node clean \ + --clean-steps '[{"step": "burnin_gpu", "interface": "deploy"}]' \ + cloudcomp100 + +.. note:: + + The current |project_name| bare metal fleet does not include GPU nodes, + so this test is not normally used. It is available for any future + hardware where GPUs are passed through to the Ironic node. + +Monitoring progress +------------------- + +While the test runs, the node is in the ``cleaning`` (or ``clean wait``) +provision state. Progress can be watched with: + +.. code-block:: console + + admin# watch -n 30 openstack baremetal node show cloudcomp100 \ + -f value -c provision_state -c last_clean_start + +The test can be aborted at any time with: + +.. code-block:: console + + admin# openstack baremetal node abort cloudcomp100 + +Multiple tests can be launched in a single call and are run in sequence: + +.. code-block:: console + + admin# openstack baremetal node clean \ + --clean-steps '[{"step": "burnin_cpu", "interface": "deploy"}, \ + {"step": "burnin_memory", "interface": "deploy"}]' \ + cloudcomp100 + +Adding ``--fast-track`` to the ``clean`` call keeps the node up between +consecutive clean calls, which shortens the overall time when several +burn-in steps are run one after another. + +When the burn-in completes, the node returns to the state it was in before +the clean was launched (``manageable`` or ``available``) and is ready for +the next stage of the node life cycle (see :ref:`ironic-node-lifecycle`). + +Collecting the results +---------------------- + +Most of the burn-in steps also report on the performance of the stressed +components, which is useful for verification or acceptance purposes. By +default, the output of the burn-in tools goes to the journal of the Ironic +Python Agent and is sent back to ironic-conductor as a log archive; on the +|project_name| deployment control plane logs are aggregated to OpenSearch +(see the Monitoring Services section of :doc:`access_to_services`). + +To store the output of individual steps in files in the ramdisk instead +(from where they can be picked up by a logging pipeline), set one of the +``agent_burnin_cpu_outputfile``, ``agent_burnin_vm_outputfile``, +``agent_burnin_fio_disk_outputfile`` or ``agent_burnin_fio_network_outputfile`` +parameters on the node: + +.. code-block:: console + + admin# openstack baremetal node set \ + --driver-info agent_burnin_cpu_outputfile='/var/log/burnin.cpu' \ + cloudcomp100 + +.. note:: + + Options set with ``openstack baremetal node set`` are not persisted in + the |kayobe_config| repository and are lost if the node is re-provisioned + through Kayobe (which regenerates ``driver-info`` from the inventory). + For a standard acceptance test this is normally fine; if a particular + configuration needs to be reapplied to many nodes, store the + ``agent_burnin_*`` options in the node's host vars under + ``etc/kayobe/inventory/host_vars//ironic`` in the |kayobe_config| + repository instead. diff --git a/source/baremetal_management_ironic_conversion.rst b/source/baremetal_management_ironic_conversion.rst new file mode 100644 index 0000000..4798169 --- /dev/null +++ b/source/baremetal_management_ironic_conversion.rst @@ -0,0 +1,222 @@ +.. include:: vars.rst + +============================= +Dynamic Hypervisor Conversion +============================= + +This section describes procedures for changing the role of nodes in the +cluster. This includes converting a bare metal node into a hypervisor and +vice versa. + +A hypervisor created by these procedures is a virtual machine launched on a +bare metal node that is managed by Ironic. The virtual machine runs a full +KVM hypervisor (nova compute), and tenant instances are scheduled onto it in +the same way as onto any other hypervisor. Because the underlying bare metal +node remains Ironic-managed, it can later be converted back to a general +purpose bare metal node when hypervisor capacity is no longer needed. + +.. note:: + It is recommended that this process is carried out inside of ``tmux`` as + one window can be used for the OpenStack client and a second window for + Kayobe commands. + The OpenStack client must be set up, making sure to install the ironic + client and acquire admin credentials. + To set up a Kayobe environment please review :doc:`working_with_kayobe`. + +Hypervisor conversion +===================== + +This procedure will enable the conversion of bare metal nodes into +hypervisors. This would be required if the current number of hypervisors is +not meeting demand. The steps outlined below cover all required changes and +commands within OpenStack and the Kayobe config. + +OpenStack commands +------------------ + +#. Source the OpenStack admin credentials:: + + source admin-openrc.sh + +#. Choose a node to convert. Make note of the desired node's resource + class:: + + openstack baremetal node show -f value -c resource_class | awk '{print tolower($0)}' + +#. Check if there is a Nova instance currently running on the node you wish + to convert:: + + openstack baremetal node show -f value -c instance_uuid + +#. If an instance is present, check if it can be safely deleted, and delete + it if so. If not, pick another node:: + + openstack server delete + +#. Wait for the node to finish deprovisioning and cleaning. It should end in + the ``available`` provision state. You can check the state using + ``baremetal node show``:: + + openstack baremetal node show -f value -c provision_state + +#. Set the active project to the hypervisors project:: + + export OS_PROJECT_NAME=|hypervisor_project_name| + unset OS_PROJECT_ID + +#. Launch a server onto the bare metal with the ``overcloud image``, on + |workload_provision_network_name|, accessible with the hypervisor SSH + key; the flavor is taken from step 2:: + + openstack server create --flavor --image --network |workload_provision_network_name| --key-name --use-config-drive -hypervisor + +#. Acquire the IP address that Neutron has assigned the hypervisor + instance:: + + openstack server show -hypervisor -f value -c addresses + +Kayobe commands +--------------- + +#. Add the hypervisor to the appropriate group within the inventory hosts + file. In the |project_name| configuration hosts are listed in the + base-layer file ``etc/kayobe/inventory/hosts``:: + + [compute_ironic_dell_hypervisor] + -hypervisor + +.. note:: + You may need to create the group that matches the resource class if one + is not already present. The new group must be added to the + ``[compute:children]`` entry in ``etc/kayobe/inventory/groups`` so that + the host is picked up as a compute host for the overcloud deployment. + +#. Apply the static physical network configuration of the switches in the + EVPN fabric. The |project_name| deployment manages its Cumulus switches + with ``kayobe physical network configure`` (see + :ref:`static-switch-config`), so no vendor-specific workaround playbook + is required. Preview the changes first:: + + kayobe physical network configure --group switches --display + + If the output looks correct, apply it:: + + kayobe physical network configure --group switches + +.. note:: + NGS continues to manage the dynamic per-port VLAN membership of the bare + metal node (see :ref:`dynamic-switch-configuration`). This step only + applies the static base configuration (trunks, MTU and EVPN settings) to + the switches. + +#. Add the IP address that Neutron assigned the hypervisor to + ``${KAYOBE_CONFIG_PATH}/environments/${KAYOBE_ENVIRONMENT}/network-allocation.yml``:: + + provision_wl_net_ips: + -hypervisor: + +#. At this point the hypervisor may be reachable over SSH via the + provision_wl IP:: + + ssh cloud-user@ + +.. note:: + If the hypervisor is not reachable check the build status of the instance + with ``openstack baremetal node show -f value -c provision_state``. + +#. Perform host configuration of the hypervisor:: + + kayobe overcloud host configure --limit -hypervisor + +#. Perform service deploy of the hypervisor:: + + kayobe overcloud service deploy -kl -hypervisor + kayobe overcloud service deploy -kl monitoring -kt prometheus + +.. note:: + After the service deploy has finished the hypervisor should be ready for + use. You can attempt to launch instances on the hypervisor using + ``openstack server create --image --flavor --network --key-name --availability-zone nova::-hypervisor -hypervisor-test-vm``. + +#. Commit the changes to the |kayobe_config| repository and open a pull + request:: + + git checkout -b add--hypervisor + git add -u + git commit -m "feat: convert baremetal to hypervisor" -m "converted: to Ironic controlled hypervisor" + git push -u origin add--hypervisor + +Baremetal conversion +==================== + +This procedure will convert hypervisors back into bare metal nodes, +effectively reverting the procedure outlined above. This would be required +if the demand for hypervisors has dropped, allowing for fewer hypervisors to +be needed. The steps outlined below cover all required changes and commands +within the Kayobe config and OpenStack. + +Kayobe commands +--------------- + +#. Source the OpenStack admin credentials:: + + source admin-openrc.sh + +#. Disable the nova compute services on the hypervisor you are converting + into a bare metal node:: + + kayobe playbook run ${KAYOBE_CONFIG_PATH}/ansible/maintenance/nova-compute-disable.yml --limit -hypervisor + +#. Drain the hypervisor of all virtual machines:: + + kayobe playbook run ${KAYOBE_CONFIG_PATH}/ansible/maintenance/nova-compute-drain.yml --limit -hypervisor + +#. Delete the hypervisor from the inventory hosts file:: + + sed -e '/-hypervisor/d' -i ${KAYOBE_CONFIG_PATH}/inventory/hosts + +#. Remove all IP allocations for the hypervisor from ``network-allocation.yml``:: + + sed -e '/-hypervisor/d' -i ${KAYOBE_CONFIG_PATH}/environments/${KAYOBE_ENVIRONMENT}/network-allocation.yml + +#. Perform a limited service deploy focusing on ``prometheus`` within the + controllers:: + + kayobe overcloud service deploy -kl monitoring -kt prometheus + +#. Commit the changes to the |kayobe_config| repository and open a pull + request:: + + git checkout -b remove--hypervisor + git add -u + git commit -m "feat: convert hypervisor to baremetal" -m "converted: back to generalist baremetal" + git push -u origin remove--hypervisor + +OpenStack commands +------------------ + +#. Source the OpenStack admin credentials:: + + source admin-openrc.sh + +#. Delete the hypervisor instance running on the bare metal:: + + openstack server delete -hypervisor + +#. Wait for the node to finish deprovisioning and to move through the + process to an ``available`` provision state. You can check the state + using ``baremetal node show``:: + + watch -n 10 -d=permanent openstack baremetal node show \ + -f yaml -c provision_state -c provision_updated_at + +#. Remove the OpenStack compute service from the disabled and drained + hypervisor:: + + openstack compute service delete -hypervisor + +.. note:: + The |project_name| deployment uses OVS, so there are no OVN controller + or metadata agents to delete manually, as would be required on an OVN + deployment. The agent registrations of the retired hypervisor are + cleaned up by Neutron once they time out. diff --git a/source/data/deployment.yml b/source/data/deployment.yml index cf3e177..b270028 100644 --- a/source/data/deployment.yml +++ b/source/data/deployment.yml @@ -12,22 +12,25 @@ cephadm: true ceph_managed: false # Whether the OpenStack deployment includes Ironic for bare metal compute. -ironic: false +ironic: true # Whether Ironic automated cleaning is enabled. ironic_automated_cleaning: true +# Whether hypervisor to bare metal conversion via Ironic is supported. +ironic_hypervisor_conversion: true + # Whether Kayobe manages physical network devices. kayobe_manages_physical_network: true # Whether the physical network is an EVPN fabric. -physical_network_evpn: false +physical_network_evpn: true # Whether the deployment includes Wazuh. -wazuh: true +wazuh: false # Whether the Wazuh deployment is managed via StackHPC. -wazuh_managed: true +wazuh_managed: false # Whether the Wazuh deployment is handled via Ansible. -wazuh_ansible: true +wazuh_ansible: false diff --git a/source/index.rst b/source/index.rst index 09ada1d..d871bc6 100644 --- a/source/index.rst +++ b/source/index.rst @@ -22,6 +22,7 @@ Contents working_with_kayobe access_to_services baremetal_management + baremetal_management_ironic_burn_in physical_network Indices and search diff --git a/source/vars.rst b/source/vars.rst index ba73f75..0a1e8e8 100644 --- a/source/vars.rst +++ b/source/vars.rst @@ -1,54 +1,57 @@ -.. |alertmanager_url| replace:: https://openstack.acme.example:9093 -.. |base_path| replace:: ~/kayobe-env -.. |bmc| replace:: BMC +.. |alertmanager_url| replace:: https://cloud.bmrc.ox.ac.uk:9093 +.. |base_path| replace:: /opt/kayobe +.. |bmc| replace:: iDRAC .. |chat_system| replace:: Slack .. |control_host_access| replace:: |control_host| is used as the Ansible control host. Each operator uses their own account on this host, but with a shared SSH key stored as ``~/.ssh/id_rsa``. -.. |control_host| replace:: acme-seed-hypervisor -.. |controller0_hostname| replace:: ``ctrl0`` -.. |controller1_hostname| replace:: ``ctrl1`` -.. |controller2_hostname| replace:: ``ctr2`` -.. |file_share_location| replace:: Google Drive -.. |flavor_name| replace:: m1.tiny -.. |floating_ip_access| replace:: from acme-seed-hypervisor and the rest of the Acme network -.. |grafana_url| replace:: https://openstack.acme.example:3000 +.. |control_host| replace:: cloudadmin000 +.. |controller0_hostname| replace:: ``cloudctrl000`` +.. |controller1_hostname| replace:: ``cloudctrl001`` +.. |controller2_hostname| replace:: ``cloudctrl002`` +.. |file_share_location| replace:: the BMRC wiki +.. |flavor_name| replace:: m1.small +.. |floating_ip_access| replace:: from the Internet +.. |grafana_url| replace:: https://cloud.bmrc.ox.ac.uk:3000 .. |grafana_username| replace:: ``grafana_local_admin`` .. |horizon_access| replace:: via the Internet. -.. |horizon_theme_clone_url| replace:: https://github.com/acme-openstack/horizon-theme.git -.. |horizon_theme_name| replace:: acme -.. |horizon_url| replace:: https://openstack.acme.example -.. |hypervisor_hostname| replace:: ``comp0`` +.. |horizon_theme_clone_url| replace:: https://github.com/bmrc-oxford/horizon-theme.git +.. |horizon_theme_name| replace:: bmrc +.. |horizon_url| replace:: https://cloud.bmrc.ox.ac.uk +.. |hypervisor_hostname| replace:: ``cloudcomp000`` +.. |hypervisor_project_name| replace:: hypervisors .. |hypervisor_type| replace:: KVM -.. |ipmi_username| replace:: admin -.. |kayobe_config_source_url| replace:: https://github.com/acme-openstack/kayobe-config.git -.. |kayobe_config_source_version| replace:: ``acme/yoga`` -.. |kayobe_config| replace:: kayobe-config -.. |kayobe_source_url| replace:: https://github.com/acme-openstack/kayobe.git -.. |kayobe_source_version| replace:: ``acme/yoga`` -.. |keystone_public_url| replace:: https://openstack.acme.example:5000 -.. |opensearch_dashboard_url| replace:: https://openstack.acme.example:5601 -.. |kolla_passwords| replace:: https://github.com/acme-openstack/kayobe-config/blob/acme/yoga/etc/kayobe/kolla/passwords.yml -.. |monitoring_host| replace:: ``mon0`` +.. |ipmi_username| replace:: root +.. |kayobe_config_source_url| replace:: https://github.com/bmrc-oxford/bmrc-kayobe-config.git +.. |kayobe_config_source_version| replace:: ``bmrc/2025.1`` +.. |kayobe_config| replace:: bmrc-kayobe-config +.. |kayobe_config_env_name| replace:: production +.. |kayobe_source_url| replace:: https://github.com/stackhpc/kayobe.git +.. |kayobe_source_version| replace:: ``stackhpc/18.4.0.1`` +.. |keystone_public_url| replace:: https://cloud.bmrc.ox.ac.uk:5000 +.. |opensearch_dashboard_url| replace:: https://cloud.bmrc.ox.ac.uk:5601 +.. |kolla_passwords| replace:: https://github.com/bmrc-oxford/bmrc-kayobe-config/blob/bmrc/2025.1/etc/kayobe/environments/production/kolla/passwords.yml +.. |monitoring_host| replace:: ``monitoring001`` .. |network_name| replace:: admin-vxlan -.. |nova_rbd_pool| replace:: acme-vms -.. |project_config_source_url| replace:: https://github.com/acme-openstack/acme-config.git -.. |project_config| replace:: acme-config -.. |project_name| replace:: Acme -.. |provisioning_net_cidr| replace:: 192.168.0.0/24 +.. |nova_rbd_pool| replace:: vms +.. |project_config_source_url| replace:: https://github.com/bmrc-oxford/bmrc-config.git +.. |project_config| replace:: bmrc-config +.. |project_name| replace:: BMRC +.. |provisioning_net_cidr| replace:: 10.151.0.0/16 .. |public_api_access_host| replace:: |control_host| -.. |public_endpoint_fqdn| replace:: openstack.acme.example -.. |public_network| replace:: public -.. |public_subnet| replace:: 10.0.0.0/8 -.. |public_vip| replace:: 10.0.0.1 -.. |reference_architecture_url| replace:: https://docs.google.com/document/u/0/?tgif=d -.. |seed_ip| replace:: 192.168.0.2 -.. |seed_name| replace:: acme-seed +.. |public_endpoint_fqdn| replace:: cloud.bmrc.ox.ac.uk +.. |public_network| replace:: br_net +.. |public_subnet| replace:: 129.67.8.128/25 +.. |public_vip| replace:: 129.67.8.131 +.. |reference_architecture_url| replace:: https://github.com/bmrc-oxford/bmrc-kayobe-config/tree/bmrc/2025.1/doc +.. |seed_ip| replace:: 10.151.1.0 +.. |seed_name| replace:: bmrc-seed .. |seed_type| replace:: virtual machine .. |seed_user| replace:: stack -.. |support_email| replace:: acme-support@stackhpc.com +.. |support_email| replace:: bmrc-cloud-ops@ndm.ox.ac.uk .. |support_level| replace:: standard support -.. |tempest_recipes| replace:: https://github.com/acme-openstack/tempest-recipes.git -.. |tls_setup| replace:: TLS is implemented using a wildcard certificate available for ``*.acme.example``. +.. |tempest_recipes| replace:: https://github.com/stackhpc/tempest-recipes.git +.. |tls_setup| replace:: TLS is implemented using a certificate available for ``cloud.bmrc.ox.ac.uk``. .. |vault_password_file_path| replace:: ~/vault-password .. |wazuh_manager_url| replace:: https://172.168.0.10:5601 .. |wazuh_manager_ip| replace:: 172.168.0.10:5601 .. |wazuh_manager_name| replace:: wazuh-manager01 +.. |workload_provision_network_name| replace:: provision_wl_net