Storage locking on VM Smart Create

[JasonRShaver]

I created a new, empty subscription and tried to follow our demo steps and ran into a number of issues relating to using an ARM template for deployment.

Example Error #1
Long running operation failed with status 'Failed' {
"status": "Failed",
"error": {
"code": "ResourceDeploymentFailure",
"message": "The resource operation completed with terminal provisioning state 'Failed'.",
"details": [
{
"code": "DeploymentFailed",
"message": "At least one resource deployment operation failed. Please list deployment operations for details. Please see http://aka.ms/arm-debug for usage details.",
"details": [
{
"code": "Conflict",
"message": "{\r\n "error": {\r\n "code": "StorageAccountAlreadyTaken",\r\n "message": "The storage account named vhdstorageki7qdyzg6loo2 is already taken."\r\n }\r\n}"
}
]
}
]
}
}

Example Error #2
Long running operation failed with status 'Failed' {
"error": {
"code": "DeploymentActive",
"message": "Unable to edit or replace deployment 'demo100vmNicIp': previous deployment from '5/27/2016 3:49:49 PM' is still active (expiration time is '6/3/2016 3:49:47 PM'). Please see http://aka.ms/arm-deploy for usage details."
}
}

[yugangw-msft]

@BurtBiel, does our VM creating guarantee the the uniqueness of the storage account? If we don't, then we should detect the conflicts and come out a better name. Imo, we should not fail though, also to let people read deployment result to figure out the cause is not optimal.

[BurtBiel]

The first example is a bad error message. This happens when you deploy a VM with different settings over the top of an old one. It could also be that the storage account it locked in Azure. I added a work item earlier that we should warn if a resource already exists, but there's nothing we can do about this case other than that.

Example 2 looks like the same VM was deployed multiple times. If the first command was cancelled and a second one was issued, you'll see this error because the previous deployment will continue until completion in the cloud. There is also nothing we can do about this besides checking all the deployment names in client-side code (duplicating the server-side code) and try to stop if any of them are still running. With unique naming of the VM however, this should never happen.

@yugangw-msft
@JasonRShaver, let me know if there are specific repro steps that you think should work in these scenarios but show errors instead.

[yugangw-msft]

Nothing left to do