Packer does not place Template in Azure Blobstore

maryamklabib commented 8 years ago

Why is packer providing us with a link to the template and the VHD in our blobstore but only the VHD is there?

@ctaymor and I configured and built an image with packer and were trying to boot it in Azure. We saw the output of the packer build command give us the URI for both the VHD and the template in our blobstore. The path it gave us was:

[name].blob.core.windows.net/system/Microsoft.Compute/Images/images/file.vhd
[name].blob.core.windows.net/system/Microsoft.Compute/Images/images/file.json

We navigated to that path and we found only the VHD in that location but did not find the json template. We looked in our portal at the blobstore, and we did not see it there either.

We ran the same packer build command with the --debug parameter and observed that the contents of the template that packer should have been placing in our blobstore were being printed in the debug output. We copied and reconstructed the output into a file and uploaded it as a template (following the remainder of the steps here) and everything went smoothly.

boumenot commented 8 years ago

Thank you for reporting an issue!

@maryamklabib What version of Packer are you using? Are you using this repository's version as a plugin? ARM support for Packer was folded into the official Packer repository (mitchellh/packer), and I recommend that you use that version (if you are not already).

At the end of a successful build for the tip of master of Mitchellh/packer, this is what I see.

StorageAccountLocation: southcentralus
OSDiskUri: https://**removed**.blob.core.windows.net/system/Microsoft.Compute/Images/images/packer-osDisk.f6635c31-86e5-4dd5-b30e-86a671b4ee8b.vhd
OSDiskUriReadOnlySas: https://**removed**.blob.core.windows.net/system/Microsoft.Compute/Images/images/packer-osDisk.f6635c31-86e5-4dd5-b30e-86a671b4ee8b.vhd?se=2016-08-14T07%3A41%3A15Z&sig=qVCfHtAhiRgapY1Ou%2FWURBh9p951m0QDZn6160BUDBo%3D&sp=r&sr=b&sv=2015-02-21
TemplateUri: https://**removed**.blob.core.windows.net/system/Microsoft.Compute/Images/images/packer-vmTemplate.f6635c31-86e5-4dd5-b30e-86a671b4ee8b.json
TemplateUriReadOnlySas: https://**removed**.blob.core.windows.net/system/Microsoft.Compute/Images/images/packer-vmTemplate.f6635c31-86e5-4dd5-b30e-86a671b4ee8b.json?se=2016-08-14T07%3A41%3A15Z&sig=fzkRLXV6Kn%2Bys5H7zjTV2XtEE3gCgECzqSkUxRcYjZo%3D&sp=r&sr=b&sv=2015-02-21

The SAS URIs allow me to download the template and OS disk. Is this what you see?

maryamklabib commented 8 years ago

@boumenot

We are using version 0.10.1
We are not using this repo's version as a plugin. We are using the official repo. (I should have made this issue there)
Yes, that's the output we see at the end of the build. However, the URIs allowed us to download the OS disk image but not the template.

boumenot commented 8 years ago

@maryamklabib

Would you rebuild with debugging enabled, and send me a gist of the logs. I cannot think of why it would succeed, but fail to produce a template in the directory. It is odd. The template is created by the backend, and we have no control over that.

Set the environment variables PACKER_LOG=1, and PACKER_LOG_PATH=packer.log, and post the resulting packer.log.

maryamklabib commented 8 years ago

@boumenot Thank you. Here it is!

https://gist.github.com/maryamklabib/d25c9b82ecdd56be30b96351c45ce7c9

Checked again in the portal and sure enough there is a new VHD file but still no template JSON file.

screen shot 2016-07-14 at 2 56 07 pm

boumenot commented 8 years ago

Don't thank me yet.

Thank you for including a screen shot, and a detailed gist. Unfortunately, I was not able to find anything in the gist to indicate why a template was not created.

The step capture image is responsible for generalizing the image and capturing the image. The capture process creates a VHD and a template in an Azure defined directory. The API allows you to control the name of the sub-directory, but Azure controls the top level directories and the names of the blobs. If the path to a VHD is system/Microsoft.Compute/Images/images, then

Azure controls: system/Microsoft.Compute.Images
API allow one to control: images

The API response in the case of your build was 200, so no error was indicated. The API docs provide no details on the creation of a template file, so I cannot speak to what may have gone wrong.

Generalize

Request

2016/07/14 14:25:27 packer: 2016/07/14 14:25:27 Azure request method="POST" request="https://management.azure.com/subscriptions/a43d33d7-17fa-441d-9b46-77f68146e4c4/resourceGroups/packer-Resource-Group-p477g6ndjy/providers/Microsoft.Compute/virtualMachines/pkrvmp477g6ndjy/generalize?api-version=2015-06-15" body=""

Response

2016/07/14 14:25:27 packer: 2016/07/14 14:25:27 Azure response status="200 OK" method="POST" request="https://management.azure.com/subscriptions/a43d33d7-17fa-441d-9b46-77f68146e4c4/resourceGroups/packer-Resource-Group-p477g6ndjy/providers/Microsoft.Compute/virtualMachines/pkrvmp477g6ndjy/generalize?api-version=2015-06-15" x-ms-request-id="95908204-0f73-418f-b071-e2878b743ccc" body=""

Capture

Request

2016/07/14 14:25:27 packer: 2016/07/14 14:25:27 Azure request method="POST" request="https://management.azure.com/subscriptions/a43d33d7-17fa-441d-9b46-77f68146e4c4/resourceGroups/packer-Resource-Group-p477g6ndjy/providers/Microsoft.Compute/virtualMachines/pkrvmp477g6ndjy/capture?api-version=2015-06-15" body="{\"vhdPrefix\":\"opsmanagertest\",\"destinationContainerName\":\"images\",\"overwriteVhds\":false}"

Response

The API polls until it gets 200. I've omitted the poll step.

2016/07/14 14:26:28 packer: 2016/07/14 14:26:28 Azure response status="200 OK" method="GET" request="https://management.azure.com/subscriptions/a43d33d7-17fa-441d-9b46-77f68146e4c4/providers/Microsoft.Compute/locations/westus/operations/8d204ac2-9e11-498e-82af-b1b1780f1d0b?api-version=2015-06-15" x-ms-request-id="921275c6-5ade-4946-a43d-b73b1049e7d2" body=

The response body includes an appropriate template. I do not know why it would not be written out along side the image.

{
    "operationId": "8d204ac2-9e11-498e-82af-b1b1780f1d0b",
    "startTime": "2016-07-14T21:25:27.8750827+00:00",
    "endTime": "2016-07-14T21:25:28.3282796+00:00",
    "status": "Succeeded",
    "properties": {
        "output": {
            "$schema": "http://schema.management.azure.com/schemas/2014-04-01-preview/VM_IP.json",
            "contentVersion": "1.0.0.0",
            "parameters": {
                "vmName": {
                    "type": "string"
                },
                "vmSize": {
                    "type": "string",
                    "defaultValue": "Standard_DS2"
                },
                "adminUserName": {
                    "type": "string"
                },
                "adminPassword": {
                    "type": "securestring"
                },
                "networkInterfaceId": {
                    "type": "string"
                }
            },
            "resources": [
                {
                    "apiVersion": "2015-06-15",
                    "properties": {
                        "hardwareProfile": {
                            "vmSize": "[parameters('vmSize')]"
                        },
                        "storageProfile": {
                            "osDisk": {
                                "osType": "Linux",
                                "name": "opsmanagertest-osDisk.91e22eee-b384-4768-b1bf-235401472e7f.vhd",
                                "createOption": "FromImage",
                                "image": {
                                    "uri": "https://opsmanagerimagewest1ssd.blob.core.windows.net/system/Microsoft.Compute/Images/images/opsmanagertest-osDisk.91e22eee-b384-4768-b1bf-235401472e7f.vhd"
                                },
                                "vhd": {
                                    "uri": "https://opsmanagerimagewest1ssd.blob.core.windows.net/vmcontainer3eb50f71-cffd-42c1-a46d-e68fdfa4d145/osDisk.3eb50f71-cffd-42c1-a46d-e68fdfa4d145.vhd"
                                },
                                "caching": "ReadWrite"
                            }
                        },
                        "osProfile": {
                            "computerName": "[parameters('vmName')]",
                            "adminUsername": "[parameters('adminUsername')]",
                            "adminPassword": "[parameters('adminPassword')]"
                        },
                        "networkProfile": {
                            "networkInterfaces": [
                                {
                                    "id": "[parameters('networkInterfaceId')]"
                                }
                            ]
                        },
                        "diagnosticsProfile": {
                            "bootDiagnostics": {
                                "enabled": false
                            }
                        },
                        "provisioningState": 0
                    },
                    "name": "[parameters('vmName')]",
                    "type": "Microsoft.Compute/virtualMachines",
                    "location": "westus"
                }
            ]
        }
    }
}

boumenot commented 8 years ago

I filled an internal incident to see if we can determine the root cause.

dsboulder commented 8 years ago

Thank you! We were using a premium storage account to store the blobs, I assume that's not the issue?

boumenot commented 8 years ago

np. It should not be an issue.

dsboulder commented 8 years ago

Any ideas yet, perhaps?

boumenot commented 8 years ago

Unfortunately, the incident has not been worked. I do not have anything to share at this time.

Is there a way to unblock you? There are good example templates that use a custom image in the Azure/quick-start-templates repository. The template emitted as a result of capture are specific to your image, which is nice, but they are missing a NIC configuration, which is not so nice. The missing NIC configuration means you must update the template before deployment.

boumenot commented 8 years ago

Sorry it took so long to get back to you on this.

It turns out that your inkling was correct, and I was wrong. The fact that it was premium storage was an issue. The internal team reported back with this.

The template is a block blob and it won’t be written to storage account if it is premium since premium storage accounts don’t support block blobs. This is by design and the user can pull the template from the output of the operation.

I will try to find a way to make this clearer in Packer, so future users are not confused. (I was.)

Azure / packer-azure