Azure
diff --git a/‎.github/copilot-instructions.md‎
Lines changed: 67 additions & 0 deletions b/‎.github/copilot-instructions.md‎
Lines changed: 67 additions & 0 deletions
diff --git a/‎.gitignore‎
Lines changed: 3 additions & 0 deletions b/‎.gitignore‎
Lines changed: 3 additions & 0 deletions
diff --git a/‎docs/OFFLINE_VALIDATION.md‎ renamed to ‎docs/HA_OFFLINE_VALIDATION.md‎ b/‎docs/OFFLINE_VALIDATION.md‎ renamed to ‎docs/HA_OFFLINE_VALIDATION.md‎
diff --git a/‎docs/HIGH_AVAILABILITY.md‎
Lines changed: 3 additions & 91 deletions b/‎docs/HIGH_AVAILABILITY.md‎
Lines changed: 3 additions & 91 deletions
diff --git a/‎docs/SETUP.MD‎
Lines changed: 101 additions & 0 deletions b/‎docs/SETUP.MD‎
Lines changed: 101 additions & 0 deletions
diff --git a/‎docs/DB_HIGH_AVAILABILITY.md‎ renamed to ‎docs/high_availability/DB_HIGH_AVAILABILITY.md‎
Lines changed: 2 additions & 2 deletions b/‎docs/DB_HIGH_AVAILABILITY.md‎ renamed to ‎docs/high_availability/DB_HIGH_AVAILABILITY.md‎
Lines changed: 2 additions & 2 deletions
@@ -0,0 +1,67 @@
+# SAP Testing Automation Framework - Copilot Instructions
+
+## Project Context
+
+This is the SAP Testing Automation Framework—an open-source orchestration tool for validating SAP deployments on Microsoft Azure. The framework focuses on HA testing for SAP HANA Scale-Up and SAP Central Services in two-node Pacemaker clusters.
+
+### Key Technologies & Architecture
+- **Primary Stack**: Python 3.10+, Ansible, Azure CLI/APIs
+- **Target Environment**: SAP on Azure (SLES/RHEL clusters)
+- **Testing Focus**: HA functional testing, configuration validation, failover scenarios
+- **Structure**: Modular design with separate modules, roles, and utilities
+- **Standards**: pytest for testing, pylint/black for code quality, 85% code coverage requirement
+
+### Project Structure Understanding
+- `src/`: Core framework code (Ansible modules, playbooks, utilities)
+- `tests/`: Comprehensive pytest test suite
+- `docs/`: Architecture and integration documentation  
+- `WORKSPACES/`: System-specific configurations and credentials
+- Key files: `pyproject.toml` (project config), Ansible playbooks for HA testing
+
+### Enterprise-Grade & OOP Defaults (mandatory)
+
+#### Enterprise-grade by default. No compromises.
+
+- Production-ready code: safe defaults, clear failure modes, strict typing, deterministic behavior.
+- Observability: structured logging, metrics hooks, and trace-friendly correlation IDs.
+- Resilience: timeouts, bounded retries with jitter/backoff, idempotency, and circuit-breaker patterns.
+- Security: least privilege, no plaintext secrets, input validation, deny-by-default.
+- Performance hygiene: avoid needless subprocess calls, batch remote ops, reduce SSH/chatty loops.
+
+##### Object-Oriented mindset for every answer and artifact.
+- Favor well-named classes with SRP, clear interfaces, and dependency inversion.
+- Encapsulate external systems (Azure, OS, Ansible runner) behind ports/adapters.
+- Model states and workflows as explicit types; avoid “stringly typed” protocols.
+- Provide seams for testing via interfaces and small, mockable collaborators.
+
+## Coding Partnership Rules
+
+Follow these rules at all times:
+
+1. **Be critical, not agreeable**:
+   - Do not just follow assumptions. Flag missing context and risky design choices.
+   - Provide counterpoints/alternatives, esp. for SAP/Azure specifics that look wrong.
+
+2. **Apply best design principles**:
+   - SOLID, DRY, KISS, clear separation of concerns.
+   - Maintainability > cleverness. Small units > god-objects.
+   - Production SAP constraints: reliability, observability, rollback plans, and operability.
+
+3. **Cover edge cases**:
+   - Empty/invalid inputs, boundary conditions, transient Azure failures, partial cluster outages,
+quorum loss, fencing misconfig, split-brain, storage throttling, DNS/MI/IMDS hiccups.
+
+4. **Output style**:
+   - Concise. Minimal yet complete code. Black-formatted, pylint-clean, ≤100-char lines.
+   - Include types, docstrings, explicit exceptions. Show tests when relevant.
+
+5. **Collaboration stance**:
+   - Act as a Principal software reviewer. Push back on weak requests or ambiguous scope.
+   - Offer 2–3 viable designs when trade-offs exist, with crisp pros/cons.
+
+## Project-Specific Guidance
+
+- **Ansible Modules**: Follow the existing module pattern with proper error handling and result objects
+- **Testing**: Maintain 85% code coverage, use pytest fixtures effectively
+- **SAP Context**: Understand HA requirements, cluster behavior, and Azure integration points
+- **Documentation**: Update relevant docs when making architectural changes
@@ -409,3 +409,6 @@ VMWPASSWORD
 .coverage.*
 *.ini
 .ansible/
+
+# GitHub Copilot configuration files
+copilot-instructions.md
@@ -28,107 +28,19 @@ Currently SAP Testing Automation Framework is supported for below Linux distros
 
 For SAP Central Services on SLES, both the simple mount approach and the classic method are supported.
 
-## Technical Requirements for running Automation Framework
-
-To run the SAP Testing Automation Framework, you must meet certain prerequisites and follow techincal requirements.
-
-### SAP System Deployment on Microsoft Azure
-
-- The SAP system must be hosted on Microsoft Azure Infrastructure-as-a-Service (IaaS).
-- The SAP system deploymed should follow SAP on Azure best practices as outlined in:
-  - [SAP HANA high availability on Azure Virtual Machine](https://learn.microsoft.com/azure/sap/workloads/sap-high-availability-guide-start).
-  - [SAP Netweaver high availability on Azure Virtual Machine](https://learn.microsoft.com/azure/sap/workloads/sap-high-availability-guide-start)
 
 ### Enabling Cluster Services on Boot
-    
+
 Before executing the tests, ensure that the cluster services are configured to start automatically during system boot. Run the following command on one of the cluster nodes to enable this setting. The `--all` option ensures that the cluster services are enabled on all nodes within the cluster.
 
 ```bash
 crm cluster enable --all  # for SUSE virtual machines
 pcs cluster enable --all  # for RedHat virtual machine
 ```
 
-### Management server
-
-The SAP Testing Automation Framework requires a jumpbox or management server with the following setup:
-
-- **Operating System**: Supported (Ubuntu 22.04 LTS, SLES 15 SP4, 15 SP6).
-- **Location**: Must be deployed on Azure.
-
-### Azure RBAC
-
-For the framework to access the properties of the Azure Load Balancer in a high availability SAP system on Azure, the management server must have a Reader role assigned to the Load Balancer. This can be done using either a system-assigned or user-assigned managed identity.
-
-#### Configuring access using system-assigned managed identity
-
-1. Enable system managed identity on the management server by following the steps in [Configure managed identities on Azure VMs](https://learn.microsoft.com/entra/identity/managed-identities-azure-resources/how-to-configure-managed-identities?pivots=qs-configure-portal-windows-vm#system-assigned-managed-identity).
-1. Open the Azure Load Balancer used for the high availability deployment of your SAP system on Azure.
-1. In the Azure Load Balancer panel, go to Access control (IAM).
-1. Follow steps from [Use managed identity to access Azure Resource](https://learn.microsoft.com/en-us/azure/role-based-access-control/role-assignments-portal) to complete the configuration.
-
-#### Configuring access using user-assigned managed identity
-
-1. Create user-assigned managed identity as described in [manage user-assigned managed identities](https://learn.microsoft.com/entra/identity/managed-identities-azure-resources/how-manage-user-assigned-managed-identities?pivots=identity-mi-methods-azp#create-a-user-assigned-managed-identity)
-1. Assign user-assigned managed identity to management server as described in [configure managed identities on Azure VMs](https://learn.microsoft.com/entra/identity/managed-identities-azure-resources/how-to-configure-managed-identities?pivots=qs-configure-portal-windows-vm#assign-a-user-assigned-managed-identity-to-an-existing-vm)
-1. Open the Azure Load Balancer used for the high availability deployment of your SAP system on Azure.
-1. In the Azure Load Balancer panel, go to Access control (IAM).
-1. Assign the required role to the user-assigned managed identity by following the steps in [assign roles using Azure portal](https://learn.microsoft.com/azure/role-based-access-control/role-assignments-portal).
-
-### Network Connectivity
-
-The management server must have network connectivity to the SAP system to perform tests and validations. You can establish this connection by peering the networks as outlined in [manage a virtual network peering](https://learn.microsoft.com/azure/virtual-network/virtual-network-manage-peering?tabs=peering-portal).
-
-### Analytics Integration (optional)
-
-- **Analytics Integration** [Telemetry Setup Information](./TELEMETRY_SETUP.md)
-  - Azure Log Analytics
-  - Azure Data Explorer
-
-## Getting Started
-
-### 1. Environment Setup
-
-To set up your environment in management server, follow these steps:
+### 1. Setup Configuration
 
-1.1. **Login to the management server**:
-
-Ensure you are logged into the management server that is connected to the SAP system's virtual network.
-
-1.2. **Install git on management server**:
-
-```bash
-# Debian/Ubuntu
-sudo su -
-apt-get install git
-
-# RHEL/CentOS
-sudo su -
-yum install git
-
-# SUSE
-sudo su -
-zypper install git
-```
-
-1.3. **Fork and clone the repository**:
-
-```bash
-# sudo to root
-sudo su -
-
-# First, visit https://github.com/Azure/sap-automation-qa in your browser
-# Click the "Fork" button in the top-right corner to create a fork in your GitHub account
-
-# Clone your fork of the repository (replace GITHUB-USERNAME with your GitHub username)
-git clone https://github.com/GITHUB-USERNAME/sap-automation-qa.git
-cd sap-automation-qa
-```
-
-1.4. **Run the initial setup script**:
-
-```bash
-./scripts/setup.sh
-```
+Follow the steps in [Setup Guide for SAP Testing Automation Framework](./SETUP.MD) to set up the framework on a management server.
 
 ### 2. Configuration
 
 
@@ -0,0 +1,101 @@
+
+# Setup Guide for SAP Testing Automation Framework
+
+## Technical Requirements for running Automation Framework
+
+To run the SAP Testing Automation Framework, you must meet certain prerequisites and follow technical requirements.
+
+### SAP System Deployment on Microsoft Azure
+
+- The SAP system must be hosted on Microsoft Azure Infrastructure-as-a-Service (IaaS).
+- The SAP system deployed should follow SAP on Azure best practices as outlined in:
+  - [SAP HANA high availability on Azure Virtual Machine](https://learn.microsoft.com/azure/sap/workloads/sap-high-availability-guide-start).
+  - [SAP Netweaver high availability on Azure Virtual Machine](https://learn.microsoft.com/azure/sap/workloads/sap-high-availability-guide-start)
+
+### Management server
+
+The SAP Testing Automation Framework requires a jumpbox or management server with the following setup:
+
+- **Operating System**: Supported (Ubuntu 22.04 LTS, SLES 15 SP4, 15 SP6, REDHAT 9.4).
+- **Location**: Must be deployed on Azure.
+
+### Azure RBAC
+
+For the framework to access the properties of the Azure Load Balancer in a high availability SAP system on Azure, the management server must have a Reader role assigned to the Load Balancer. This can be done using either a system-assigned or user-assigned managed identity.
+
+#### Configuring access using system-assigned managed identity
+
+1. Enable system managed identity on the management server by following the steps in [Configure managed identities on Azure VMs](https://learn.microsoft.com/entra/identity/managed-identities-azure-resources/how-to-configure-managed-identities?pivots=qs-configure-portal-windows-vm#system-assigned-managed-identity).
+1. Open the Azure Load Balancer used for the high availability deployment of your SAP system on Azure.
+1. In the Azure Load Balancer panel, go to Access control (IAM).
+1. Follow steps from [Use managed identity to access Azure Resource](https://learn.microsoft.com/en-us/azure/role-based-access-control/role-assignments-portal) to complete the configuration.
+
+#### Configuring access using user-assigned managed identity
+
+1. Create user-assigned managed identity as described in [manage user-assigned managed identities](https://learn.microsoft.com/entra/identity/managed-identities-azure-resources/how-manage-user-assigned-managed-identities?pivots=identity-mi-methods-azp#create-a-user-assigned-managed-identity)
+1. Assign user-assigned managed identity to management server as described in [configure managed identities on Azure VMs](https://learn.microsoft.com/entra/identity/managed-identities-azure-resources/how-to-configure-managed-identities?pivots=qs-configure-portal-windows-vm#assign-a-user-assigned-managed-identity-to-an-existing-vm)
+1. Open the Azure Load Balancer used for the high availability deployment of your SAP system on Azure.
+1. In the Azure Load Balancer panel, go to Access control (IAM).
+1. Assign the required role to the user-assigned managed identity by following the steps in [assign roles using Azure portal](https://learn.microsoft.com/azure/role-based-access-control/role-assignments-portal).
+
+### Network Connectivity
+
+The management server must have network connectivity to the SAP system to perform tests and validations. You can establish this connection by peering the networks as outlined in [manage a virtual network peering](https://learn.microsoft.com/azure/virtual-network/virtual-network-manage-peering?tabs=peering-portal).
+
+### Analytics Integration (optional)
+
+- **Analytics Integration** [Telemetry Setup Information](./TELEMETRY_SETUP.md)
+  - Azure Log Analytics
+  - Azure Data Explorer
+
+## Getting Started
+
+### 1. Environment Setup
+
+To set up your environment in management server, follow these steps:
+
+1.1. **Login to the management server**:
+
+Ensure you are logged into the management server that is connected to the SAP system's virtual network.
+
+1.2. **Install git on management server**:
+
+```bash
+# Debian/Ubuntu
+sudo su -
+apt-get install git
+
+# RHEL/CentOS
+sudo su -
+yum install git
+
+# SUSE
+sudo su -
+zypper install git
+```
+
+1.3. **Fork and clone the repository**:
+
+```bash
+# sudo to root
+sudo su -
+
+# First, visit https://github.com/Azure/sap-automation-qa in your browser
+# Click the "Fork" button in the top-right corner to create a fork in your GitHub account
+
+# Clone your fork of the repository (replace GITHUB-USERNAME with your GitHub username)
+git clone https://github.com/GITHUB-USERNAME/sap-automation-qa.git
+cd sap-automation-qa
+```
+
+1.4. **Run the initial setup script**:
+
+```bash
+./scripts/setup.sh
+```
+
+1.5. **Activate the python environment**:
+
+```bash
+source .venv/bin/activate
+```
@@ -4,8 +4,8 @@
 
 | Test Case | Type | Description | More Info |
 |-----------|-----------|-------------| --------- |
-| HA Parameters Validation | Configuration |  The HA parameter validation test validates HA configuration including Corosync settings, Pacemaker resources, SBD device configuration, and HANA system replication setup. | [ha-config.yml](../src/roles/ha_db_hana/tasks/ha-config.yml) |
-| Azure Load Balancer | Configuration |  The Azure LB configuration test validates Azure Load Balancer setup including health probe configuration, backend pool settings, load balancing rules, and frontend IP configuration. | [azure-lb.yml](../src/roles/ha_db_hana/tasks/azure-lb.yml) |
+| HA Parameters Validation | Configuration |  The HA parameter validation test validates HA configuration including Corosync settings, Pacemaker resources, SBD device configuration, and HANA system replication setup. | [ha-config.yml](../../src/roles/ha_db_hana/tasks/ha-config.yml) |
+| Azure Load Balancer | Configuration |  The Azure LB configuration test validates Azure Load Balancer setup including health probe configuration, backend pool settings, load balancing rules, and frontend IP configuration. | [azure-lb.yml](../../src/roles/ha_db_hana/tasks/azure-lb.yml) |
 | Resource Migration | Failover | The Resource Migration test validates planned failover scenarios by executing controlled resource movement between HANA nodes. It performs a graceful migration of the primary HANA resources to the secondary node, verifies proper role changes, ensures cluster maintains stability throughout the transition, and validates complete data synchronization after migration. | [resource-migration.md](./pseudocode/resource-migration.md) |
 | Primary Node Crash | Failover | The Primary Index Server Crash test simulates cluster behavior when the HANA index server crashes on the primary node. It simulates an index server failure by forcefully terminating the process, then verifies automatic failover to the secondary node, monitors system replication status, and confirms service recovery without data loss. | [node-crash.md](./pseudocode/node-crash.md) |
 | Block Network | Network | The Block Network test validates cluster behavior during network partition scenarios by implementing iptables rules to block communication between primary and secondary HANA nodes. It verifies split-brain prevention mechanisms, validates proper failover execution when nodes become isolated, and ensures cluster stability and data consistency after network connectivity is restored. | [block-network.md](./pseudocode/block-network.md) |