Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Data source azurerm_shared_image_version is not returning the actual latest version #13175

Closed
melcloud opened this issue Aug 29, 2021 · 5 comments · Fixed by #14708
Closed

Data source azurerm_shared_image_version is not returning the actual latest version #13175

melcloud opened this issue Aug 29, 2021 · 5 comments · Fixed by #14708

Comments

@melcloud
Copy link

melcloud commented Aug 29, 2021

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform (and AzureRM Provider) Version

  • Terraform version: 1.0.5
  • Azure provider version: 2.74.0

Affected Resource(s)

  • `data.azurerm_shared_image_version1st

Terraform Configuration Files

data "azurerm_shared_image_version" "latest" {
  name = "latest"
  gallery_name = azurerm_shared_image.example.gallery_name
  image_name = azurerm_shared_image.example.name
  resource_group_name = azurerm_shared_image.example.resource_group_name
}

Debug Output

Since we have more than 20 images, the API return images in batches and a token to get the latest. However, the provider only find the latest in the first batch. This has been fixed in data source azurerm_shared_image_versions

Panic Output

Expected Behaviour

Return image of the latest

Actual Behaviour

Return latest image in the first batch

Steps to Reproduce

  1. terraform apply

Important Factoids

References

@burnedikt
Copy link

burnedikt commented Nov 3, 2021

I've also stumbled upon this and was quite confused since it was claimed to be fixed in by #10519 in version 2.47.0. However, I definitely still face the same behaviour and I think this is also the same issue as #10581. I also want to add #10516 as a reference from the past where this issue was raised initially.

It appears that the fix back then was only applied to azurerm_shared_image_versions (obtaining a list of all image versions withint a shared image gallery) but not to azurerm_shared_image_version (obtaining a single version by name or keyword latest / recent).


As a workaround for now, I use the working azurem_shared_image_versions data source to get all versions and then use the last version in the list to reproduce the same behaviour as I would get with a working version of azurem_shared_image_version and trying to obtain latest like:

# obtain all versions, the last version in that list will be the "latest" version
data "azurerm_shared_image_versions" "versions" {
  image_name          = "my-shared-image-name"
  gallery_name        = "my-shared-image-gallery-name"
  resource_group_name = "my-resource-group-name"
}

data "azurerm_shared_image_version" "main" {
  name                = reverse(data.azurerm_shared_image_versions.main.images)[0].name
  image_name          = "my-shared-image-name"
  gallery_name        = "my-shared-image-gallery-name"
  resource_group_name = "my-resource-group-name"
}

This effectively reproduces the behaviour of azurerm_shared_image_version with name as latest, see

// the last image in the list is the latest version
if len(images.Values()) > 0 {
image := images.Values()[len(images.Values())-1]
return &image, nil
}

@gek0
Copy link

gek0 commented Dec 20, 2021

Hello, I'm having issues with this resource since nor the latest or recent parameters work for the name attribute
https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/data-sources/shared_image_version#name

We are using a standardized versioning policy - MAJOR.MINOR.PATCH for our images
Example: 1.0.1, 1.0.9, 1.0.10 and so on...
When needed we bump the MINOR and MAJOR numbers, but PATCH is incremented for regular builds

Current situation: we've built the image versioned to 1.0.10 but 1.0.9 is returned due to a sorting issue

Example golang code that could fix this - take into account "numeric" string for versioning

package main

import (
	"fmt"
	"sort"
	"strconv"
)

func main() {
	s := []string{"1.0.1", "1.0.8", "1.0.9", "1.0.10"}
	sort.Strings(s)
	fmt.Printf("Before: %v\n", s)

	s2 := []string{"1.0.1", "1.0.8", "1.0.9", "1.0.10"}
	sort.Slice(s2, func(i, j int) bool {
		numA, _ := strconv.Atoi(s2[i])
		numB, _ := strconv.Atoi(s2[j])
		return numA < numB
	})

	fmt.Printf("After: %v\n", s2)
}

and the resulting output -> where Before is what currently the provider returns

Before: [1.0.1 1.0.10 1.0.8 1.0.9]
After: [1.0.1 1.0.8 1.0.9 1.0.10]

Can somebody take a look at this and fix it upstream if valid?
At least the recent parameter should work but not sure if that is checking the timestamp metadata or name? Looks like the functionality is the same and broken

@favoretti
Copy link
Collaborator

Hi and thanks all for reporting this issue. For my understanding - from what I can see in the docs - the version can be anything really, so Atoi approach would fail on anything that's not a numeric version. This makes it kinda hard to sort deterministically. Ay ideas are appreciated here.

@github-actions
Copy link

github-actions bot commented Jan 7, 2022

This functionality has been released in v2.91.0 of the Terraform Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you!

@github-actions
Copy link

github-actions bot commented Feb 7, 2022

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 7, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants