Fix VM actions when workspace storage doesn't allow shared key access

[tamirkamara]

Resolves #4221

What is being addressed

Workspace storage that doesn't allow shared key access blocks any VM activity post initial deployment.

How is this addressed

• The TF data object can't be used as that uses shared key to access Azure Files. Since the only usage of the object is to get the share name which we anyway receive as a variable (and pass in the data object), we can just remove it and use the variable directly. This will remove the need for TF to reference the Azure Files object and avoid this problem.

[github-actions]

Unit Test Results

0 tests   0 ✅  0s ⏱️
0 suites  0 💤
0 files    0 ❌

Results for commit 2299dd1.

♻️ This comment has been updated with latest results.

[tamirkamara]

/test-extended

[github-actions]

🤖 pr-bot 🤖

🏃 Running extended tests: https://github.com/microsoft/AzureTRE/actions/runs/12493778693 (with refid fc97343a)

(in response to this comment from @tamirkamara)

[jonnyry]

Hi @tamirkamara have you seen this error when running the extended e2e before? I received the same error running error on my azurerm version upgrade PR as well…

https://github.com/microsoft/AzureTRE/actions/runs/12483029966

Trying to figure out what’s causing the osdisk resource to be left over, but not had much luck so far.

[tamirkamara]

@jonnyry I don't know how but the behavior of the os disk auto delete has changed and removing the VM doesn't auto delete its disks. I checked and the relevant TF setting has existed in AzureRM 3+ so this isn't it probably... At any case, I will update this PR retest and see if it works.

[tamirkamara]

Actually, this is where it comes from: https://registry.terraform.io/providers/hashicorp/Azurerm/latest/docs/guides/features-block#skip_shutdown_and_force_delete-1
@marrobi was too fast on the trigger here (and me as well to approve :-)) I will revert the prior change.

[tamirkamara]

/test-extended

[github-actions]

🤖 pr-bot 🤖

🏃 Running extended tests: https://github.com/microsoft/AzureTRE/actions/runs/12495737490 (with refid fc97343a)

(in response to this comment from @tamirkamara)

[jonnyry]

Actually, this is where it comes from: https://registry.terraform.io/providers/hashicorp/Azurerm/latest/docs/guides/features-block#skip_shutdown_and_force_delete-1 @marrobi was too fast on the trigger here (and me as well to approve :-)) I will revert the prior change.

Ah great spot thanks 🙏

[marrobi]

Sorry, my fault. Does it need this?

https://registry.terraform.io/providers/a2m1/azurerm/latest/docs/guides/features-block#delete_os_disk_on_deletion-1

[tamirkamara]

Sorry, my fault. Does it need this?

https://registry.terraform.io/providers/a2m1/azurerm/latest/docs/guides/features-block#delete_os_disk_on_deletion-1

@marrobi No. First, that last setting is anyway set to true. Secondly, the setting you used is meant for immediate delete while keeping the resources behind to make them available for attachment to another VM.

[github-actions]

🤖 pr-bot 🤖

🏃 Running extended tests: https://github.com/microsoft/AzureTRE/actions/runs/12495737490 (with refid fc97343a)

(in response to this comment from @tamirkamara)

[LizaShak]

LGTM. Left only one tiny comment

[tamirkamara]

/test-force-approve
The pipeline failed in an unrelated place.

[github-actions]

🤖 pr-bot 🤖

✅ Marking tests as complete (for commit 2299dd1)

(in response to this comment from @tamirkamara)