Skip to content

Add SAP Configuration Checks to STAF #129

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 13 commits into from
Oct 14, 2025
Merged

Add SAP Configuration Checks to STAF #129

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
13 commits
Select commit Hold shift + click to select a range
b11e497
Add SAP Configuration Checks to STAF
devanshjainms Oct 14, 2025
574052f
Refactor playbook name determination and update configuration checks …
devanshjainms Oct 14, 2025
a1cc3de
Refactor conditional statements for improved readability in disk and …
devanshjainms Oct 14, 2025
88ba965
Refactor conditional statements for improved readability in configura…
devanshjainms Oct 14, 2025
3a75f6d
Merge branch 'development-oct-2025' into configuration-checks
devanshjainms Oct 14, 2025
06b2083
Add SAP Configuration Checks documentation and setup instructions
devanshjainms Oct 14, 2025
ba6b31a
Fix documentation for configuration checks to use TEST_TYPE instead o…
devanshjainms Oct 14, 2025
9f0eaba
Add permissions requirements for high availability and configuration …
devanshjainms Oct 14, 2025
561ac8e
Update HANA configuration checks for high availability command and va…
devanshjainms Oct 14, 2025
b39b2e8
Rename expected_output to valid_list in HANA configuration checks
devanshjainms Oct 14, 2025
76dddf1
Fix typo in permissions section and clarify role assignments for high…
devanshjainms Oct 14, 2025
f5e01cc
Enhance execute_command_subprocess tests to validate output for both …
devanshjainms Oct 14, 2025
010cf8a
Fix formatting in execute_command_subprocess test for clarity
devanshjainms Oct 14, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions .ansible-lint
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,7 @@ exclude_paths:
- .github
- src/roles/ha_db_hana/tasks/files/
- src/roles/ha_scs/tasks/files/
- src/roles/configuration_checks/tasks/files/

skip_list:
- no-handler
Expand Down
114 changes: 114 additions & 0 deletions docs/CONFIGURATION_CHECKS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,114 @@
# 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

Configuration validation serves as a critical quality gate in the SAP deployment lifecycle by:

- **Validating Azure Infrastructure**: Ensuring compute, storage, and network configurations align with SAP best practices
- **Verifying SAP Parameters**: Checking critical SAP HANA and application server settings
- **Assessing Cluster Health**: Validating Pacemaker configurations and resource constraints
- **Ensuring Compliance**: Confirming adherence to organizational and SAP security standards

## Configuration Check Categories

**Azure Compute**
- VM SKU appropriateness for SAP workloads
- Accelerated Networking enablement
- Availability Set/Zone configuration
- Proximity Placement Group setup

**Storage Configuration**
- Premium SSD/Ultra Disk usage for critical paths
- Write Accelerator for log volumes
- Storage account redundancy settings
- Disk caching policies

**SAP HANA Configuration**
- Memory allocation
- System replication parameters

**Pacemaker Cluster**
- Resource agent versions and parameters
- Fencing (STONITH) configuration
- Resource constraints and colocation rules
- Cluster communication settings

**SAP HA Resources**
- Virtual hostname configuration
- File system mount options
- Service startup ordering
- Failover timeout values


### 1. Setup Configuration

Follow the steps (1.1 - 1.5) in [Setup Guide for SAP Testing Automation Framework](./SETUP.MD) to set up the framework on a management server.

### 2. System Configuration

Update the `TEST_TYPE` parameter in [`vars.yaml`](./../vars.yaml) file to `ConfigurationChecks` to enable the Configuration Checks test scenarios.

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.


### 3. Test Execution

To execute the script, run following command:

```bash
# Help option
./scripts/sap_automation_qa.sh --help

# Run all the configuration checks with default parameters
./scripts/sap_automation_qa.sh

# Run checks with verbose logging
./scripts/sap_automation_qa.sh -vv

# Run only Database (HANA) configuration checks
./scripts/sap_automation_qa.sh --extra-vars='{"configuration_test_type":"Database"}'

# Run only ASCS/ERS configuration checks
./scripts/sap_automation_qa.sh --extra-vars='{"configuration_test_type":"CentralServiceInstances"}'

# Run only Application Server configuration checks
./scripts/sap_automation_qa.sh --extra-vars='{"configuration_test_type":"ApplicationInstances"}'
```

### 4. Viewing Test Results

After the test execution completes, a detailed HTML report is generated that summarizes the PASS/FAIL status of each test case and includes detailed execution logs for every step of the automation run.

**To locate and view your test report:**

1. **Navigate to your SAP system’s workspace directory:**

Replace `<SYSTEM_CONFIG_NAME>` with the name of your SAP system configuration (for example, `DEV-WEEU-SAP01-X00`):

```bash
cd WORKSPACES/SYSTEM/<SYSTEM_CONFIG_NAME>/quality_assurance/
```
2. **Find your report file:**

The report file is named using the following 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 distribution (e.g., SLES15SP4)
- `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)

3. **View the report**

You can open the HTML report in any web browser to review the results and logs.
238 changes: 4 additions & 234 deletions docs/HIGH_AVAILABILITY.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -40,194 +40,13 @@ pcs cluster enable --all # for RedHat virtual machine

### 1. Setup Configuration

Follow the steps in [Setup Guide for SAP Testing Automation Framework](./SETUP.MD) to set up the framework on a management server.
Follow the steps (1.1 - 1.5) in [Setup Guide for SAP Testing Automation Framework](./SETUP.MD) to set up the framework on a management server.

### 2. Configuration
### 2. System Configuration

#### 2.1. Test Environment Configuration
Update the `TEST_TYPE` parameter in [`vars.yaml`](./../vars.yaml) file to `SAPFunctionalTests` to enable the High Availability test scenarios.

2.1.1. Navigate to the root directory

```bash
cd sap-automation-qa
```

2.1.2. Update `vars.yaml` with your test parameters. This file contains the variables used in the test cases:

```yaml
# The type of test to be executed. Supported values are:
# - SAPFunctionalTests
TEST_TYPE: "SAPFunctionalTests"

# The type of SAP functional test to be executed. Supported values are:
# - DatabaseHighAvailability
# - CentralServicesHighAvailability
sap_functional_test_type: "DatabaseHighAvailability" # or "CentralServicesHighAvailability"

# The name of the SAP system configuration for which you want to execute the test cases.
# It would be the name of the folder under 'WORKSPACE/SYSTEM/' where it could find hosts.yaml, sap-parameters.yaml files of the SAP system configuration
SYSTEM_CONFIG_NAME: "DEV-WEEU-SAP01-X00"

# The type of authentication to be used for the telemetry data destination. Supported values are: VMPASSWORD and SSHKEY
AUTHENTICATION_TYPE:

# The destination of the telemetry data. Supported values are:
# - azureloganalytics
# - azuredataexplorer (only recommended for long-term storage)
telemetry_data_destination: "azureloganalytics"

# The name of the telemetry table in the telemetry data destination.
telemetry_table_name: "your-telemetry-table-name"

# The workspace id, shared key of the Log Analytics workspace.
laws_shared_key: "your-log-analytics-shared-key"
laws_workspace_id: "your-log-analytics-workspace-id"

# The cluster name, data ingestion URI, and client ID of the Azure Data Explorer.
adx_cluster_fqdn: "your-adx-cluster-fqdn"
adx_database_name: "your-adx-database-name"
ade_client_id: "your-adx-client-id"
```

#### 2.2. System Configuration (WORKSPACES)

Create your system workspace. This directory contains the configuration files specific to your SAP system, necessary for connecting to the system and executing test scenarios. The `WORKSPACE/SYSTEM/` directory holds sub-directories, each representing a different [SAP system](./WORKSPACES/SYSTEM/DEV-WEEU-SAP01-X00).

```bash
cd WORKSPACES/SYSTEM
mkdir ENV-REGION-VNET-SID
cd ENV-REGION-VNET-SID
```

The system workspace should include the following files, containing all necessary details about the SAP system.

2.2.1. **hosts.yaml** - System [Inventory file](https://docs.ansible.com/ansible/latest/inventory_guide/intro_inventory.html) (required)

This file contains the connection details for the SAP system hosts and is used as an inventory file by the Ansible framework to connect to the SAP system. You can find the inventory file in the path [hosts.yaml](../WORKSPACES/SYSTEM/DEV-WEEU-SAP01-X00/hosts.yaml).

Here is an example of the hosts.yaml file format:

```yaml
X00_DB:
hosts:
hostname0:
ansible_host: "IP_ADDRESS0"
ansible_user: "USERNAME"
ansible_connection: "ssh"
connection_type: "key"
virtual_host: "VIRTUAL_HOSTNAME0"
become_user: "USERNAME1" #Username with root privilege
os_type: "linux"
vm_name: "AZURE_VM_NAME0"
hostname1:
ansible_host: "IP_ADDRESS1"
ansible_user: "USERNAME"
ansible_connection: "ssh"
connection_type: "key"
virtual_host: "VIRTUAL_HOSTNAME1"
become_user: "USERNAME1" #Username with root privilege
os_type: "linux"
vm_name: "AZURE_VM_NAME1"
vars:
node_tier: "hana" # or "ers", "scs"
```

In the file:

- X00 represents the SAP SID (System ID) of the SAP system, followed by the host type (e.g., DB, ASCS, PAS). You must provide the SAP SID of the system, regardless of whether you are testing Database High Availability or Central Services High Availability.

The file includes the following details:

- **ansible_host**: The IP address of the host.
- **ansible_user**: The user for connecting to the host.
- **ansible_connection**: The connection type (usually "ssh").
- **connection_type**: The connection type, used when connecting via SSH key (not needed for password-based connections).
- **virtual_host**: The virtual host name of the SCS/DB host.
- **become_user**: The user with root privileges. For example, user "azureadm" must be able to change to root without password.
- **os_type**: The operating system type (e.g., Linux or Windows).
- **vm_name**: The computer name of the Azure VM.
- **node_tier**: The type of node tier. Supported values: hana, ers, scs.

2.2.2. **sap-parameters.yaml** - SAP Configuration (required)

This file contains the SAP system configuration parameters. The parameters are used by the test scenarios to validate the system's high availability configuration. You can find the inventory file in the path [sap-parameters.yaml](../WORKSPACES/SYSTEM/DEV-WEEU-SAP01-X00/sap-parameters.yaml).

Here is an example of the sap-parameters.yaml file format:

```yaml
# The SAP and Database SID of the SAP system.
sap_sid: "your-sap-sid"
db_sid: "your-db-sid"

# Boolean indicating if the SCS and database is configured as highly available.
scs_high_availability: true
database_high_availability: true

# The high availability configuration of the SCS and DB instance. Supported values are:
# - AFA (for Azure Fencing Agent)
# - ISCSI (for SBD devices with ISCSI target servers)
# - ASD (for SBD devices with Azure Shared Disks)
scs_cluster_type: "AFA" # or "ISCSI" or "ASD"
database_cluster_type: "AFA" # or "ISCSI" or "ASD"

# The instance number of the SCS, ERS and DB instance.
scs_instance_number: "00"
ers_instance_number: "01"
db_instance_number: "00"

# The type of database. Supported values are:
# - HANA
platform: "HANA"

# The NFS provider used for shared storage. Supported values are:
# - ANF (for Azure NetApp Files)
# - AFS (for Azure File Share)
NFS_provider: "ANF" # or "AFS"

# If you're using a user-assigned managed identity (as explained in "Azure RBAC" section above):
# - Enter the client ID of that identity here
# - You can find this ID in Azure Portal → Managed Identities → Your Identity → Properties → Client ID
# If you're using system-assigned managed identity instead:
# - Leave this blank or set to empty string ""
user_assigned_identity_client_id: "000000-00000-00000-00000-000000"

# If you have the SSH key or VM password stored in an Azure Key Vault as a secret:
# - Enter the Azure Key Vault Resource ID in the key_vault_id parameter and the Secret ID in the secret_id parameter.
# - You can find the Resource ID of the Key Vault in Azure Portal → Key Vaults → Your Key Vault → JSON view → Copy the Resource ID
# - You can find the Resource ID of the Secret in Your Key Vault → Secrets → Select Secret → Current Version → Copy the Secret Identifier
# If you're creating SSHKEY or VMPASSWORD file locally:
# - Remove the following two parameters
key_vault_id: /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.KeyVault/vaults/<key-vault-name>
secret_id: https://<key-vault-name>.vault.azure.net/secrets/<secret-name>/<id>
```

2.2.3. **Credential Files** (Available locally)

The required credential files depend on the authentication method used to connect to the SAP system:

1. **SSH Key Authentication**: If connecting via SSH key, place the private key inside `WORKSPACE/SYSTEM/<DIRECTORY>` and name the file "ssh_key.ppk".
1. **Password Authentication**: If connecting using a username and password, create a password file by running the following command. It takes the username from hosts.yaml file.

```bash
echo "password" > WORKSPACES/SYSTEM/<DIRECTORY>/password
```

2.2.4. **Credential Files** (From Azure Key Vault)

When using Azure Key Vault to store credentials, the framework retrieves authentication details directly from the key vault using the configured managed identity.

**Authentication Methods:**

1. **SSH Key Authentication**: Store the private SSH key content in Azure Key Vault as a secret.
2. **Password Authentication**: Store the password in Azure Key Vault as a secret. The username is taken from the `hosts.yaml` file.

**Setup:**

1. Ensure the managed identity has "Key Vault Secrets User" role on the key vault.

2. Configure `key_vault_id` and `secret_id` parameters in `sap-parameters.yaml` as shown in section 2.2.2.

**Important**: When using Key Vault authentication, do NOT create local credential files (`ssh_key.ppk` or `password` files).
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.


### 3. Test Execution
Expand Down Expand Up @@ -279,52 +98,3 @@ After the test execution completes, a detailed HTML report is generated that sum
3. **View the report**

You can open the HTML report in any web browser to review the results and logs.

## Update the framework

To ensure you have the latest features and fixes, it's important to keep your fork of the SAP Testing Automation Framework up to date. You can do this by pulling the latest changes from the original repository into your fork.

### Steps to update your fork

1. **Ensure you have the upstream repository configured**:

```bash
# Check if you already have the upstream remote
git remote -v

# If you don't see an 'upstream' entry, add it
git remote add upstream https://github.com/Azure/sap-automation-qa.git
```

2. **Fetch the latest changes from the upstream repository**:

```bash
git fetch upstream
```

3. **Ensure you're on your main branch**:

```bash
git checkout main
```

4. **Merge the changes from upstream into your local fork**:

```bash
git merge upstream/main
```

5. **Push the updated code to your GitHub fork**:

```bash
git push origin main
```

This process will update your fork with all the latest features, bug fixes, and improvements from the original SAP Testing Automation Framework repository.

> **NOTE**
> If you've made local changes to your fork, you might encounter merge conflicts during step 4. In that case, you'll need to resolve these conflicts before proceeding with the push in step 5.

## Additional Resources

- [Azure SAP Documentation](https://docs.microsoft.com/azure/sap)
Loading
Loading