Minor changes to STAF documentation (#144)

dennispadia · web-flow · commit 15051b5962f0 · 2025-10-27T12:16:19.000-07:00
diff --git a/README.md b/README.md
@@ -23,7 +23,7 @@ SAP Testing Automation is designed as a scalable framework to orchestrate and va
 >
 > The High Availability testing scenario in the SAP Testing Framework is **generally available (GA)**, while the Configuration Checks scenario is currently in **public preview**.
 
-### High Availability Testing 
+### High Availability Testing
 
 In the SAP Testing Automation Framework, thorough validation of high availability SAP HANA scale-up and SAP Central Services failover mechanism in a two node pacemaker cluster can be performed, ensuring the system operates correctly across different situations.
 
diff --git a/docs/CONFIGURATION_CHECKS.md b/docs/CONFIGURATION_CHECKS.md
@@ -1,12 +1,10 @@
 # SAP Configuration Checks
 
-## Overview
-
 SAP Configuration Checks is an integral part of the SAP Testing Automation framework, providing comprehensive validation of SAP system configurations on Azure infrastructure. This module ensures that SAP Database and SAP Central Services deployments meet enterprise requirements for compliance before entering production. This tool is designed to identify misconfigurations, deviations from best practices, and potential issues that could impact system's stability and performance.
 
 This tool is a new version of the existing [Quality Checks scripts](https://github.com/Azure/SAP-on-Azure-Scripts-and-Utilities/tree/main/QualityCheck), re-architected to provide a extensible, and maintainable solution. It leverages Python for core logic and Ansible for orchestration.
 
-## Purpose
+## Overview
 
 Configuration validation serves as a critical quality gate in the SAP deployment lifecycle by:
 
@@ -20,30 +18,27 @@ Configuration validation serves as a critical quality gate in the SAP deployment
 The configuration checks are organized into logical groups that can be executed independently or all at once. The main categories are:
 
 1. **Infrastructure**
-
-      - While not a separate execution category, infrastructure checks are performed as part of the other categories.
-      - **Azure Compute**: VM SKU, Accelerated Networking, Availability Set/Zone, Proximity Placement Group.
-      - **Storage**: Use of Premium SSD/Ultra Disk, Write Accelerator, disk caching policies, and redundancy settings.
+   - While not a separate execution category, infrastructure checks are performed as part of the other categories.
+   - **Azure Compute**: VM SKU, Accelerated Networking, Availability Set/Zone, Proximity Placement Group.
+   - **Storage**: Use of Premium SSD/Ultra Disk, Write Accelerator, disk caching policies, and redundancy settings.
 
 2. **Database**
-
    - Validates SAP HANA or IBM DB2 specific settings.
    - **SAP HANA**: Checks memory allocation, system replication parameters, and Pacemaker cluster configurations (resource agents, fencing, constraints).
    - **IBM DB2**: Verifies hardware requirements, system language, and OS tuning parameters.
 
 3. **Central Services**
+   - Validates the configuration of ASCS (ABAP SAP Central Services) and ERS (Enqueue Replication Server) instances.
+   - Checks for virtual hostname configuration, file system mount options, and service startup ordering.
 
-      - Validates the configuration of ASCS (ABAP SAP Central Services) and ERS (Enqueue Replication Server) instances.
-
-      - Checks for virtual hostname configuration, file system mount options, and service startup ordering.
+4. **Application Servers**
+   - Validates the configuration of the application server instances.
 
+> [!NOTE]
+>
+> High Availability (HA) configuration checks and functional tests are currently supported only for SAP HANA databases. For IBM DB2 databases, only non-HA configuration checks are available.
 
-3. **Application Servers**
-      - Validates the configuration of the application server instances.
-
-
-> **Note**: High Availability (HA) configuration checks and functional tests are currently supported only for SAP HANA databases. For IBM DB2 databases, only non-HA configuration checks are available.
-
+## Pre-requisites
 
 ### 1. Setup Configuration
 
@@ -55,20 +50,18 @@ Update the `TEST_TYPE` parameter in [`vars.yaml`](./../vars.yaml) file to `Confi
 
 Follow the steps (2.1 - 2.2) in [Setup Guide for SAP Testing Automation Framework](./SETUP.MD#2-system-configuration) to configure your system details.
 
-> **Note**: High Availability (HA) configuration checks and functional tests are currently supported only for SAP HANA databases. For IBM DB2 databases, only non-HA configuration checks are available.
-
 ### 3. Required Access and Permissions (required)
 
-Effective configuration validation requires that the management server's managed identity (system or user assigned) has read permissions on all target Azure resources. This allows the framework to inspect the settings of services including, but not limited to, Azure Load Balancers, storage solutions (Managed Disks, Azure Files, Azure NetApp Files), and network infrastructure. Lacking the necessary access will prevent the configuration checks from identifying potential misconfigurations in the environment. For more details on configuring system assigned managed identity vs user assigned managed identity, see [Setup Guide for SAP Testing Automation Framework](./SETUP.MD#configuring-access-using-managed-identity).
+Effective configuration validation requires that the management server's managed identity (system or user assigned) has read permissions on all target Azure resources. This allows the framework to inspect the settings of services including, but not limited to, Azure Load Balancers, storage solutions (Managed Disks, Azure Files, Azure NetApp Files), and network infrastructure. Lacking the necessary access will prevent the configuration checks from identifying potential misconfigurations in the environment. For more details on configuring system assigned managed identity vs user assigned managed identity, see [Setup Guide for SAP Testing Automation Framework](./SETUP.MD#4-identity-and-authorization).
 
 1. Depending on the type of managed identity method you want to use, configure managed identity on management server
-   - [Configuring access using system-assigned managed identity](./SETUP.MD#configuring-access-using-system-assigned-managed-identity).
-   - [Configuring access using user-assigned managed identity](SETUP.MD#configuring-access-using-user-assigned-managed-identity).
+   - [Configuring access using user-assigned managed identity](./SETUP.MD#option-1-user-assigned-managed-identity).
+   - [Configuring access using system-assigned managed identity](./SETUP.MD#option-2-system-assigned-managed-identity).
 2. Grant the managed identity (system- or user-assigned) the built-in **Reader** role on every resource group that contains SAP system components (VMs, managed disks, load balancers, virtual network, shared storage such as Azure NetApp Files or Azure Files). If everything resides in a single resource group, one assignment there is sufficient; if components are split across multiple resource groups, add a **Reader** role assignment on each resource group to allow the configuration checks to read and validate all infrastructure settings.
 
-### 4. Azure Login (required)
+## Test Execution
 
-Ensure that you are logged into Azure CLI on the management server VM with the appropriate subscription context:
+You first need to make sure that you are logged into Azure CLI on the management server VM with the appropriate subscription context:
 
 ```bash
 # Login to Azure using System Assigned Managed Identity
@@ -81,8 +74,6 @@ az login --identity -u <client-id-of-user-assigned-managed-identity>
 az account set --subscription <subscription-id>
 ```
 
-### 5. Test Execution
-
 To execute the script, run following command:
 
 ```bash
@@ -105,7 +96,7 @@ To execute the script, run following command:
 ./scripts/sap_automation_qa.sh --extra-vars='{"configuration_test_type":"ApplicationInstances"}'
 ```
 
-### 6. Viewing Test Results
+## Viewing Test Results
 
 After the test execution completes, a detailed HTML report is generated. The report provide the summary of each test cases that got executed for each VM.
 
@@ -118,21 +109,21 @@ After the test execution completes, a detailed HTML report is generated. The rep
    ```bash
    cd WORKSPACES/SYSTEM/<SYSTEM_CONFIG_NAME>/quality_assurance/
    ```
-   
+  
 2. **Find your report file:**
 
    The report file is named using the following format:
 
-   ```
+   ```html
    all_{DISTRO}_{INVOCATION_ID}.html
    ```
 
    - `DISTRO`: Linux distribution (SLES or RHEL)
 
    - `INVOCATION_ID`: A unique identifier (Group invocation ID) for the test run which is logged at the end of test execution. Find example screenshot below:
 
-      ![Test Execution Completion Screenshot](./images/execution_screenshot.png)
+   ![Test Execution Completion Screenshot](./images/execution_screenshot.png)
 
 3. **View the report**
 
-   You can open the HTML report in any web browser to review the results and logs.
+   You can open the HTML report in any web browser to review the results and logs.
diff --git a/docs/HIGH_AVAILABILITY.md b/docs/HIGH_AVAILABILITY.md
@@ -30,9 +30,21 @@ Follow the steps in the [Setup Guide for SAP Testing Automation Framework](./SET
 
 ### 3. Configure the System for HA Testing
 
-1.  Update the `TEST_TYPE` parameter in the `vars.yaml` file to `SAPFunctionalTests` to enable the High Availability test scenarios.
-2.  Follow the steps in the [System Configuration section of the Setup Guide](./SETUP.MD#2-system-configuration) to provide the details of your SAP system.
+1. Update the `TEST_TYPE` parameter in the `vars.yaml` file to `SAPFunctionalTests` to enable the High Availability test scenarios.
+2. Follow the steps in the [System Configuration section of the Setup Guide](./SETUP.MD#2-system-configuration) to provide the details of your SAP system.
 
+### 4. Required Access and Permission (required for Load Balancer)
+
+In the High Availability testing scenario, one of the test cases validates the configuration of the Azure Load Balancer used in the SAP high availability setup. To retrieve the properties of the Azure Load Balancer, the management server VM must have read access to it.
+
+Access can be granted by configuring a managed identity for the management server. For more information on setting up system-assigned or user-assigned managed identities, see [Setup Guide for SAP Testing Automation Framework](./SETUP.MD#4-identity-and-authorization).
+
+1. Depending on the type of managed identity method you want to use, configure managed identity on management server.
+
+   - [Configuring access using user-assigned managed identity](./SETUP.MD#option-1-user-assigned-managed-identity).
+   - [Configuring access using system-assigned managed identity](./SETUP.MD#option-2-system-assigned-managed-identity).
+
+1. Grant the managed identity (system- or user-assigned) the built-in **Reader** role on the Azure load balancer used in the SAP high availability cluster configuration.
 
 ## Test Execution
 
@@ -56,26 +68,26 @@ Execute the tests using the `sap_automation_qa.sh` script from the `scripts` dir
 
 Upon completion, the framework generates a detailed HTML report that summarizes the PASS/FAIL status of each test case and provides detailed execution logs.
 
-1.  **Navigate to the workspace directory for your SAP system.**
+1. **Navigate to the workspace directory for your SAP system.**
 
-    Replace `<SYSTEM_CONFIG_NAME>` with the name of your SAP system configuration (e.g., `DEV-WEEU-SAP01-X00`).
+   Replace `<SYSTEM_CONFIG_NAME>` with the name of your SAP system configuration (e.g., `DEV-WEEU-SAP01-X00`).
 
-    ```bash
-    cd WORKSPACES/SYSTEM/<SYSTEM_CONFIG_NAME>/quality_assurance/
-    ```
+   ```bash
+   cd WORKSPACES/SYSTEM/<SYSTEM_CONFIG_NAME>/quality_assurance/
+   ```
 
-2.  **Identify the report file.**
+2. **Identify the report file.**
 
-    The report file name follows this format:
-    `HA_{SAP_TIER}_{DATABASE_TYPE}_{OS_DISTRO_NAME}_{INVOCATION_ID}.html`
+   The report file name follows this format:
+   `HA_{SAP_TIER}_{DATABASE_TYPE}_{OS_DISTRO_NAME}_{INVOCATION_ID}.html`
 
-    *   `SAP_TIER`: The SAP tier tested (e.g., DB, SCS).
-    *   `DATABASE_TYPE`: The database type (e.g., HANA).
-    *   `OS_DISTRO_NAME`: The operating system (e.g., SLES15SP4).
-    *   `INVOCATION_ID`: A unique identifier for the test run, which is logged at the end of the test execution.
+   - `SAP_TIER`: The SAP tier tested (e.g., DB, SCS).
+   - `DATABASE_TYPE`: The database type (e.g., HANA).
+   - `OS_DISTRO_NAME`: The operating system (e.g., SLES15SP4).
+   - `INVOCATION_ID`: A unique identifier for the test run, which is logged at the end of the test execution.
 
-    ![Test Execution Completion Screenshot](./images/execution_screenshot.png)
+   ![Test Execution Completion Screenshot](./images/execution_screenshot.png)
 
-3.  **View the report.**
+3. **View the report.**
 
-    Open the HTML file in any web browser to review the test results and logs.
+   Open the HTML file in any web browser to review the test results and logs.

Original file line number	Diff line number	Diff line change
`@@ -23,7 +23,7 @@ SAP Testing Automation is designed as a scalable framework to orchestrate and va`
`23`	`23`	`>`
`24`	`24`	`> The High Availability testing scenario in the SAP Testing Framework is generally available (GA), while the Configuration Checks scenario is currently in public preview.`
`25`	`25`
`26`		`-### High Availability Testing`
	`26`	`+### High Availability Testing`
`27`	`27`
`28`	`28`	`In the SAP Testing Automation Framework, thorough validation of high availability SAP HANA scale-up and SAP Central Services failover mechanism in a two node pacemaker cluster can be performed, ensuring the system operates correctly across different situations.`
`29`	`29`