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

When using Azure Compute Gallery image as base, using image_id fails but using image_name/image_version works #13036

Closed
sabuncumurat opened this issue Jun 10, 2024 · 3 comments

Comments

@sabuncumurat
Copy link

sabuncumurat commented Jun 10, 2024

I have the following pkr.hcl file:

source "azure-arm" "from-sig" {
  
  build_resource_group_name = "packer-build"
  
  shared_image_gallery {
    subscription        = "<subscription-id>"
    resource_group      = "MyImages"
    gallery_name        = "MyGallery"
    image_name          = "pkrgenimg"
    image_version       = "2.2.3"
  }
  
  shared_image_gallery_destination {
    subscription        = "<subscription-id>"
    resource_group      = "MyImages"
    gallery_name        = "MyGallery"
    image_name          = "pkrgenimg"
    image_version       = "6.4.0"
    target_region {
      name = "northeurope"
    }

    ...
  }

The above works and version 6.4.0 of the image in question is generated successfully from version 2.2.3, as intended. All good.

When I replace image_name and image_version in the shared_image_gallery block with either community_gallery_image_id or direct_shared_gallery_image_id, the image generation fails:

  shared_image_gallery {
    subscription        = "<subscription-id>"
    resource_group      = "MyImages"
    direct_shared_gallery_image_id = "/subscriptions/<subscription-id>/resourceGroups/MyImages/providers/Microsoft.Compute/galleries/MyGallery/images/pkrgenimg/versions/2.2.3"
  }

PowerShell session error:

==> azure-arm.from-sig: ERROR: -> DeploymentFailed : At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/arm-deployment-operations for usage details.
==> azure-arm.from-sig: ERROR: -> BadRequest : Id /subscriptions/<subscription-id>/resourceGroups/MyImages/providers/Microsoft.Compute/galleries//images/ is not a valid resource reference.

Please note that in the second line of the error above, the Id string after BadRequest is missing components after the galleries part.

If this is not a bug, what is the proper way to use an image_id in a shared_image_gallery block?

And a related question - when the above image build fails, three artifacts are left behind and not cleaned up:

image

I have to remove them manually.

I am under the impression that Packer is supposed to clean up even in case of an error. Is this really the case?

Thank you.

Copy link

Hi 👋 thanks for reaching out.

For general questions we recommend reaching out to the [community forum](https://discuss.hashicorp.com/c/packer) for greater visibility.
As the GitHub issue tracker is only watched by a small subset of maintainers and is really reserved for bugs and enhancements, you'll have a better chance of finding someone who can help you in the forum.
We'll mark this issue as needs-reply to help inform maintainers that this question is awaiting a response.
If no activity is taken on this question within 30 days it will be automatically closed.

If you find the forum to be more helpful or if you've found the answer to your question elsewhere please feel free to post a response and close the issue.

Copy link

This issue has been migrated to hashicorp/packer-plugin-azure#424 due to the Packer Plugin split.

Please follow the new issue for updates.

Copy link

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 Jul 16, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants