[BUG] "development" branch failed on "playbook_01_os_base_config.yaml" on "suse:sles-sap-15-sp5/6:gen2:latest" PC image: "zypper lr" returns 6

[lilyeyes]

Describe the bug
I tried version v3.13.0.1 this playbook can pass.

I was trying this branch as I hit an issue (playbook_04_00_00_db_install.yaml hangs on TASK [roles-os/1.17-generic-pacemaker : 1.17 Generic Pacemaker - Enable Stonith] ***, I will open another bug later) on suse:sles-sap-15-**sp6**:gen2:latest PC images.
I though "#664" (Feature: Enable SAPHanaSR-angi configuration for scale-up configurations) might fix my issue as "development" branch includes #664.

The development branch failed on playbook_01_os_base_config.yaml on suse:sles-sap-15-**sp5/6**:gen2:latest PC images.
It reports:

fatal: [qesdhdb01l0f1]: FAILED! => {
    "changed": false,
    "cmd": [
        "zypper",
        "lr"
    ],
    "delta": "0:00:00.048474",
    "end": "2024-12-06 01:08:52.439419",
    "invocation": {
        "module_args": {
            "_raw_params": "zypper lr",
...
        }
    },
    "msg": "non-zero return code",
    "rc": 6,
...
    "stdout": "Warning: No repositories defined.\nUse the 'zypper addrepo' command to add one or more repositories.",
    "stdout_lines": [
        "Warning: No repositories defined.",
        "Use the 'zypper addrepo' command to add one or more repositories."
    ]
}

To reproduce
List of executed playbooks:

pb_get-sshkey.yaml
playbook_00_validate_parameters.yaml
playbook_01_os_base_config.yaml
playbook_02_os_sap_specific_config.yaml
playbook_03_bom_processing.yaml
playbook_04_00_00_db_install.yaml
playbook_04_00_01_db_ha.yaml
playbook_07_00_00_post_installation.yaml
playbook_08_00_00_post_configuration_actions.yaml

Expected behavior
I tried version v3.13.0.1 this playbook can pass. So development should pass too.

Additional context
This is a result of testing SDAF using OpenQA test framework.

[hdamecharla]

@lilyeyes thanks for reporting this.

If you have deployed these systems via SDAF terraform modules, could you kindly confirm that the VM images variables are set as following? for example, the database_vm_image is outlined below.

database_vm_image = {
  os_type = "LINUX",
  source_image_id = "",
  publisher = "SUSE",
  offer = "sles-sap-15-sp6",
  sku = "gen2",
  version = "latest",
  type = "marketplace"
}

[lilyeyes]

database_vm_image

If using "development" branch this issue can found on both sp5 and sp6 imgs (I only tried these 2 images ATM).
I did not found database_vm_image but found source_image_reference:

# module.hdb_node.azurerm_linux_virtual_machine.vm_dbnode[0] will be created
  + resource "azurerm_linux_virtual_machine" "vm_dbnode" {
...
      + source_image_reference {
          + offer     = "sles-sap-15-sp6"
          + publisher = "suse"
          + sku       = "gen2"
          + version   = "2024.08.08"
        }
    }

or

      + source_image_reference {
          + offer     = "sles-sap-15-sp6"
          + publisher = "suse"
          + sku       = "gen2"
          + version   = "latest"
        }

[hdamecharla]

Thank you, for the additional information. Could you also confirm if this issue is a recurring one, please?

While I have used the SP6 image for our internal testing, I did not encounter similar issues before creating PR to the development branch. I will investigate this and get back to you.

Relevant sections from the logs

024-11-22T14:39:01.6116615Z   + resource "azurerm_linux_virtual_machine" "vm_dbnode" {
2024-11-22T14:39:01.6116856Z       + admin_username                                         = (sensitive value)
2024-11-22T14:39:01.6117594Z       + computer_name                                          = (known after apply)
2024-11-22T14:39:01.6117824Z       + disable_password_authentication                        = true
...
...
2024-11-22T14:39:01.6131078Z       + source_image_reference {
2024-11-22T14:39:01.6131338Z           + offer     = "sles-sap-15-sp6"
2024-11-22T14:39:01.6131534Z           + publisher = "SUSE"
2024-11-22T14:39:01.6131713Z           + sku       = "gen2"
2024-11-22T14:39:01.6131910Z           + version   = "latest"
2024-11-22T14:39:01.6132073Z         }
2024-11-22T14:39:01.6132220Z     }

024-11-22T15:15:36.7078648Z                         "sh7dhdb00l06f": {
2024-11-22T15:15:36.7078863Z                             "_ansible_no_log": false,
2024-11-22T15:15:36.7079077Z                             "action": "ansible.builtin.command",
2024-11-22T15:15:36.7079290Z                             "changed": false,
2024-11-22T15:15:36.7079473Z                             "cmd": [
2024-11-22T15:15:36.7079647Z                                 "zypper",
2024-11-22T15:15:36.7079819Z                                 "lr"
2024-11-22T15:15:36.7080004Z                             ],
2024-11-22T15:15:36.7080195Z                             "delta": "0:00:00.059865",
2024-11-22T15:15:36.7080496Z                             "end": "2024-11-22 15:08:37.639090",
2024-11-22T15:15:36.7080705Z                             "invocation": {
2024-11-22T15:15:36.7080899Z                                 "module_args": {
2024-11-22T15:15:36.7081110Z                                     "_raw_params": "zypper lr",
...
...
2024-11-22T15:15:36.7083075Z                                 }
2024-11-22T15:15:36.7083252Z                             },
2024-11-22T15:15:36.7083421Z                             "msg": "",
2024-11-22T15:15:36.7083594Z                             "rc": 0,
2024-11-22T15:15:36.7083872Z                             "start": "2024-11-22 15:08:37.579225",

[lilyeyes]

Yes, this issue is is a recurring one if using development branch .