[AVM Question/Feedback]: Dev-ops-infrastructure/pool - Image reference unclear

[SebastianClaesson]

Check for previous/existing GitHub issues

• I have checked for previous/existing GitHub issues

Description

Hi,

Reference AVM; https://github.com/Azure/bicep-registry-modules/tree/main/avm/res/dev-ops-infrastructure/pool

When setting the image name, I can see that in all examples it's set as "< wellKnownImageName >/latest".

bicep-registry-modules/avm/res/dev-ops-infrastructure/pool/tests/e2e/defaults/main.test.bicep

Lines 63 to 67 in a237334

	images: [
	{
	wellKnownImageName: 'windows-2022/latest'
	}
	]

Reference:
https://github.com/Azure/bicep-registry-modules/blob/main/avm/res/dev-ops-infrastructure/pool/README.md#example-1-using-only-defaults

However Microsoft Learn does not have this documented:
https://learn.microsoft.com/en-us/azure/devops/managed-devops-pools/configure-images?view=azure-devops&tabs=arm#azure-pipelines-image-predefined-aliases

Is it necessary to set /latest in the wellKnownImageName reference, or is it just to be explicit that it's the latest produced image that is used.
And leaving it without "/latest" would produce the same result?

Or is the effect something else when excluding "/latest" in the image reference?

Thanks!
/Sebastian

[microsoft-github-policy-service]

Important

The "Needs: Triage 🔍" label must be removed once the triage process is complete!

Tip

For additional guidance on how to triage this issue/PR, see the BRM Issue Triage documentation.

[bjompen]

Hey Sebastian.

I believe the issue is more "unclear docs" than an issue with the module. The AVM module parameter is which images to support in the Managed DevOps pool, as per this setting in the portal:

The list is all the image versions you can select as per this specific image. Specifying "Latest" will make sure you always have the lates build of, for example, windows-server-2019, where you may also specify one specific build to be static.

The learn docs linked on the other hand is talking about "built in aliases". In your Azure DevOps YAML you can use aliases as image override, and select runner type. You may also set additional aliases in the AVM module using images - Aliases as seen in this example

The confusion, and a fully understandable one, is that aliases and image references uses almost the same names but is actually different settings. Add to this that the Azure Pipelines images have no other version but latest as per point number one above.

Additionally - The confusion is made extra big since we have the Azure pipelines - Ubuntu 22.04 image that is set using the value wellKnownImageName": "ubuntu-22.04/latest", and the Ubuntu server 22.04 LTS - x64 Gen 2 that is set using the value "resourceId": "/subscriptions/50665426-d41e-4227-bab7-b3dbb4e4c76c/Providers/Microsoft.Compute/Locations/westeurope/publishers/canonical/artifacttypes/vmimage/offers/0001-com-ubuntu-server-jammy/skus/22_04-lts-gen2/versions/latest"

I hope this clears it up a bit, and that the docs gets some improvement on this topic.

//Björn

[bjompen]

Oh, I may have misread stuff.. You are of course correct about the docs also, but the link provided was to the Alias chapter.

Looking at the official learn docs for ARM deployment and Choose your pools image we see that here they do not include latest in the version, where as in the AVM module they do. Someone with insight in the ARM/AVM settings may better answer if latest if needed (and update docs) or not (and update AVM module) :)

[microsoft-github-policy-service]

Warning

Tagging the AVM Core Team (@Azure/avm-core-team-technical-bicep) due to a module owner or contributor having not responded to this issue within 3 business days. The AVM Core Team will attempt to contact the module owners/contributors directly.

Tip

• To prevent further actions to take effect, the "Status: Response Overdue 🚩" label must be removed, once this issue has been responded to.
• To avoid this rule being (re)triggered, the ""Needs: Triage 🔍" label must be removed as part of the triage process (when the issue is first responded to)!

[microsoft-github-policy-service]

Warning

Tagging the AVM Core Team (@Azure/avm-core-team-technical-bicep) due to a module owner or contributor having not responded to this issue within 3 business days. The AVM Core Team will attempt to contact the module owners/contributors directly.

Tip

• To prevent further actions to take effect, the "Status: Response Overdue 🚩" label must be removed, once this issue has been responded to.
• To avoid this rule being (re)triggered, the ""Needs: Triage 🔍" label must be removed as part of the triage process (when the issue is first responded to)!

[microsoft-github-policy-service]

Caution

**This issue requires the AVM Core Team's (@Azure/avm-core-team-technical-bicep) immediate attention as it hasn't been responded to within 6 business days. **

Tip

• To avoid this rule being (re)triggered, the "Needs: Triage 🔍" and "Status: Response Overdue 🚩" labels must be removed when the issue is first responded to!
• Remove the "Needs: Immediate Attention ‼️" label once the issue has been responded to.

[AlexanderSehr]

Hey @SebastianClaesson,
please note, that for these kind of issues it would be best to open a 'module issue' as it automatically assigns the module's owner. I'll do this now manually, so please just keep it in mind for next time 😉

[AlexanderSehr]

Hey @elizatargithub7 & @surajguptha, please advice when you get the chance :)

bicep-registry-modules/avm/res/dev-ops-infrastructure/pool/tests/e2e/defaults/main.test.bicep

Lines 63 to 67 in a237334

	images: [
	{
	wellKnownImageName: 'windows-2022/latest'
	}
	]

[microsoft-github-policy-service]

Warning

Tagging the AVM Core Team (@Azure/avm-core-team-technical-bicep) due to a module owner or contributor having not responded to this issue within 3 business days. The AVM Core Team will attempt to contact the module owners/contributors directly.

Tip

• To prevent further actions to take effect, the "Status: Response Overdue 🚩" label must be removed, once this issue has been responded to.
• To avoid this rule being (re)triggered, the ""Needs: Triage 🔍" label must be removed as part of the triage process (when the issue is first responded to)!

[microsoft-github-policy-service]

Caution

**This issue requires the AVM Core Team's (@Azure/avm-core-team-technical-bicep) immediate attention as it hasn't been responded to within 6 business days. **

Tip

• To avoid this rule being (re)triggered, the "Needs: Triage 🔍" and "Status: Response Overdue 🚩" labels must be removed when the issue is first responded to!
• Remove the "Needs: Immediate Attention ‼️" label once the issue has been responded to.

[AlexanderSehr]

Hey @SebastianClaesson,
in the meantime - how did your deployments go? Did you face any errors?

I just checked the REST API invovcation (CREATE) and can at least say that also the resourceId parameter is documented with a /latest flag. Yet I would not be suprised if there's some logic in the backend that automatically appands that suffix if none was provided.

[SebastianClaesson]

Hey @SebastianClaesson, in the meantime - how did your deployments go? Did you face any errors?

I just checked the REST API invovcation (CREATE) and can at least say that also the resourceId parameter is documented with a /latest flag. Yet I would not be suprised if there's some logic in the backend that automatically appands that suffix if none was provided.

Hi @AlexanderSehr ,

The deployment has been fine, it is just unclear if /latest flag is needed or not!
So far it seems that the behavious is as expected (backend appends /latest) as our images seem to be updating accordingly.

[elizatargithub7]

The latest flag is not needed, if it's missing, our service will add it.

[SebastianClaesson]

Thanks! I'll close the issue, this is the answer I was looking for (and expected!)