VM Deployment succeeds even when VM model is bad

[colemickens]

CLI Version: 0.10.2 (node: 4.2.6) OS Type: Mac / Win / Linux (Ubuntu, RedHat, etc.) Linux - Ubuntu 16.04 Installation via: npm / brew / win-or-mac installer / docker / github repo Arch AUR package

Mode: ARM

Environment: AzureCloud

---

I downloaded quickstart templates, went into 101-customdata and removed the base64() function around the customdata parameter and also changed the GEN- values.   Ran this:

azure group create colemick-customdata-test --template-file ./azuredeploy.json --parameters-file ./azuredeploy.parameters.json --location "westus"

The deployment appears to have succeeded from the CLI.   Looking in the portal though, the VM is clearly missing. Looking at the JSON event in the audit log:  

[...snipped...]
"properties": {
        "statusCode": "BadRequest",
        "serviceRequestId": "e143ce7f-cc08-4b8c-b605-9e981421c6b4",
        "statusMessage": "{\"error\":{\"code\":\"InvalidParameter\",\"target\":\"customData\",\"message\":\"Custom data in OSProfile must be in Base64 encoding and with a maximum length of 87380 characters.\"}}"
   },
[...snipped...]

---

I expected to have the deployment failure surfaced back to the CLI.

[amarzavery]

The following command will provide you logs about the deployment as well. Using it with --json provides detailed logs.

azure group log show -h
help:    Retrieves and shows logs for resource group operations
help:    
help:    Usage: group log show [options] [name]
help:    
help:    Options:
help:      -h, --help                        output usage information
help:      -v, --verbose                     use verbose output
help:      -vv                               more verbose with debug output
help:      --json                            use json output
help:      -n --name <name>                  the resource group name
help:      -a --all                          returns logs for all operations (including CRUD and deployment)
help:      -l --last-deployment              returns logs for the last deployment
help:      -d --deployment <name>            the name of the deployment whose logs you want to see
help:      -s --subscription <subscription>  the subscription identifier
help:    
help:    Current Mode: arm (Azure Resource Management)

What does azure group deployment show return? Would be curious to know.

[amarzavery]

@ravbhatnagar @vivsriaus - Please take a look at this issue.

[vivsriaus]

@colemickens I tried doing the same - downloaded the template, removed base64() around custom data, and edited the params file like you mentioned. However, I'm not able to reproduce the issue. My deployment succeeds in CLI and in portal. I'm using the latest CLI version (0.10.6). Can you please retry and let us know if you continue to run into the issue you see? If yes, please send us the template file and the param file you used for deployment, along with a screen shot of the CLI console saying the deployment succeeded, and the portal indicating the deployment failed.

FWIW, here is the template and param files I used to reproduce the issue: https://github.com/vivsriaus/armtemplates/blob/master/customdatatemplate.json https://github.com/vivsriaus/armtemplates/blob/master/params.json

Deployment succeeded in CLI: info: Resource 'vm1' of type 'Microsoft.Compute/virtualMachines' provisioning status is Succeeded info: Resource 'j5d7tyzixw6ymsacustmdata' of type 'Microsoft.Storage/storageAccounts' provisioning status is Succeeded info: Resource 'networkInterface1' of type 'Microsoft.Network/networkInterfaces' provisioning status is Succeeded info: Resource 'publicIp1' of type 'Microsoft.Network/publicIPAddresses' provisioning status is Succeeded info: Resource 'virtualNetwork1' of type 'Microsoft.Network/virtualNetworks' provisioning status is Succeeded data: DeploymentName : customdatatemplate data: ResourceGroupName : vtest data: ProvisioningState : Succeeded data: Timestamp : Thu Oct 13 2016 14:52:41 GMT-0700 (Pacific Daylight Time) data: Mode : Incremental data: CorrelationId : 346083dc-1ae9-42d4-a184-15be310ee85d data: DeploymentParameters : data: Name Type Value data: --------------- ------------ ----------- data: dnsLabelPrefix String vivsriaus data: adminUsername String admin123 data: adminPassword SecureString undefined data: customData String whatever data: vmSize String Standard_D2 data: ubuntuOSVersion String 14.04.2-LTS info: group deployment create command OK

Deployment succeeded in portal

cc/ @ravbhatnagar

[colemickens]

Then the platform must have changed to automatically base64 encode CustomData if it isn't already. Right? Can we confirm that change was made? I mean, the error (Custom data in OSProfile must be in Base64 encoding and with a maximum length of 87380 characters.) came from somewhere back in August when I filed this.

[vivsriaus]

@colemickens Possible, but I'd have to confirm that with the service teams. Do you still have the logs from the portal for the failed deployment? What would help me debug is information like subscription id, correlation id, timestamp - these can help me narrow down the issue to see if this was something caused by our service (ARM), or by portal or the Compute RP.

[colemickens]

I'm sorry, there's about zero chance of me finding that at this point. The service request ID is in the original post though.

By the way, your template didn't actually deploy a VM from the log you posted... might be why you didn't see the failure.

[vivsriaus]

@colemickens Nope, my template DID deploy a VM:

[colemickens]

Ack, sorry, missed it in the log output earlier.

Not really sure. Azure has always required customData to be base64 encoded, including in August when I filed this. We need someone from ARM/platform to weigh in and tell us if this behavior has changed.

[jseely]

I've also had this issue with custom ARM templates. One example which makes azure group deployment create fail is deploying a VM to a subnet that has not been created. In this case the deployment command sets the return code to 0 even though the deployment failed.

[vivsriaus]

@jseely

In this case the deployment command sets the return code to 0 even though the deployment failed.

This has been fixed in the latest cli release (0.10.6) with this PR

[jseely]

Awesome thanks @vivsriaus