Replace azurerm vm with azurerm_linux

[BillAnastasiadis]

This pr replaces all cases of azurerm_virtual_machine, which is deprecated, with azurerm_linux_virtual_machine. The conversion demanded a LOT of other changes as well, as the 2 resources have a lot of differences in the way they define and use their components.

Some of the differences (they are too many to list all of them) are:

• Data disks that were defined inside the azurerm_virtual_machine resource, now need to be defined as a separate resource together with an attachment resource that binds them to the respective VMs.
• That also lead to changes in the way the names of the disks are calculated, since some of them used VM specific counts. I did the changes with the goal of ending up with the same exact names in the end.
• vm_size renamed to size
• The os_profile and os_profile_linux_config blocks are replaced with top-level arguments in azurerm_linux_virtual_machine
• delete_os_disk_on_termination and delete_data_disks_on_termination attributes are removed from the azurerm_linux_virtual_machine resource. The first is now moved to provider level and renamed (provider->features->delete_os_disk_on_deletion), while the second has disappeared completely (!!) and is no longer doable in terraform. Ricardo said thet pcw takes care of that cleanup
• boot_diagnostics changes: enabled attribute no longer supported, while storage_uri is renamed to storage_account_uri
• ... and more.

LINKS:

• Related ticket: https://jira.suse.com/browse/TEAM-8424
• Verification Runs:

HanaSr-Azure-(BYOS|PAYG):
15sp3 BYOS:
https://openqaworker15.qa.suse.cz/tests/236441 🟢

Qesap-Azure-(BYOS|PAYG) (failure after deployment expected):
15sp5:
https://openqaworker15.qa.suse.cz/tests/236437 red is later after the deployment and quite like due to TEAM-8442
15sp4:
https://openqaworker15.qa.suse.cz/tests/236439 red is later after the deployment and quite like due to TEAM-8442
12sp5:
https://openqaworker15.qa.suse.cz/tests/237155 🟢
http://openqaworker15.qa.suse.cz/tests/237156 red is later after the deployment and quite like due to TEAM-8442

qesap-azure-saptune-uri:
https://openqa.suse.de/tests/12325535 red is later after the deployment and quite like due to TEAM-8442

[mpagot]

No changes to propose but some questions and one more VR to run

[mpagot]

Why this rework was needed?

 dynamic "source_image_reference" {
    for_each = var.sles4sap_uri != "" ? [] : [1]
    content {
      publisher = module.os_image_reference.publisher
      offer     = module.os_image_reference.offer
      sku       = module.os_image_reference.sku
      version   = module.os_image_reference.version
    }
  }

  source_image_id = var.sles4sap_uri != "" ? join(",", azurerm_image.sles4sap.*.id) : null

This deserve a dedicated VR

[BillAnastasiadis]

Because source_image_id was no longer supported inside the dynamic "source_image_reference", which replaces storage_image_reference. Now there's source_image_reference for catalogue images, and source_image_id for custome images, but documentation states

NOTE:
One of either source_image_id or source_image_reference must be set.

I resorted to that code that checks for the existance of var.sles4sap_uri and uses one or the other accordingly. It's basically the same logic as the existing code, just with the id separated as a different var outside the reference as the new specification states

[alvarocarvajald]

Thanks for the explanation Bill. I guess that means we need a VR for each method the image can be supplied, either via an URI which would mean we are testing an unpublished image from the Build Service, or by submitting a publisher, version, sku, etc, meaning we are testing on a catalog image.

[lpalovsky]

LGTM

[alvarocarvajald]

LGTM, but I think we need to add more verification runs to cover more the changes.

[mpagot]

LGTM

[BillAnastasiadis]

LGTM, but I think we need to add more verification runs to cover more the changes.

@alvarocarvajald suggest away! I'm running another one based on https://openqa.suse.de/tests/12289218, feel free to ask for others as well

[alvarocarvajald]

LGTM, but I think we need to add more verification runs to cover more the changes.

@alvarocarvajald suggest away! I'm running another one based on https://openqa.suse.de/tests/12289218, feel free to ask for others as well

Off the top of my head, I'd say some from https://openqa.suse.de/group_overview/285 (HanaSR on PAYG and BYOS, saptune on PAYG & BYOS) which deal with unreleased OS images, and then perhaps some from https://openqaworker15.qa.suse.cz/group_overview/41 (I'd say 15-SP5 and 12-SP5, since you already have a passing one with 15-SP3). Finally some saptune ones from https://openqaworker15.qa.suse.cz/group_overview/46 (saptune on 15-SP5 PAYG mostly, since the previous 15-SP5 ones are BYOS) and the same from https://openqaworker15.qa.suse.cz/group_overview/28 (saptune on 12-SP5 ... but last MU which triggered tests in this job group is 18 days old, so leave this last one as optional)

[a-kpappas]

@BillAnastasiadis Some VRs failed. Do you know why?

(The operation was succesful. The patient died.)

[BillAnastasiadis]

@BillAnastasiadis Some VRs failed. Do you know why?

(The operation was succesful. The patient died.)

@a-kpappas someone edited the description and answered :D

[a-kpappas]

LGTM