azure_data_disk.test-data: Error adding data disk 0 to instance test-vm: Error response from Azure.

[rksinghal]

I am not able to attach data disk to vm. Able to create host service, storage service and vm but not able to attach data disk. Getting following error:

* azure_data_disk.test-data: Error adding data disk 0 to instance test-vm: Error response from Azure. Code: ResourceNotFound, Message: The deployment name 'test-vm' does not exist.

tf file:

resource "azure_hosted_service" "test" {
    name = "test"
    location = "East US 2"
    ephemeral_contents = false
}

resource "azure_storage_service" "testst" {
    name = "testst"
    location = "East US 2"
    account_type = "Standard_LRS"
}

resource "azure_instance" "test-vm" {
    name = "test-vm"
    image = "Ubuntu Server 14.04 LTS"
    size = "Basic_A1"
    location = "East US 2"
    hosted_service_name = "test"
    storage_service_name = "testst"
    depends_on = "azure_storage_service.testst"

    count = 1
}

resource "azure_data_disk" "test-data" {
    name = "test-data"
    lun = 0
    size = 128
    storage_service_name = "testst"
    virtual_machine = "${azure_instance.test-vm.id}"
    depends_on = "azure_instance.test-vm""
}

[kbxkb]

Facing the same issue. Issue, most probably is this: the directive "virtual_machine" for the azure_data_disk resource is looking for a deployment by that name instead of just looking for a virtual machine. Would like to have this fixed quickly, thanks!

[progre55]

Yup, facing the same problem here.

[kbxkb]

Just tested that this problem only exists if you are trying to add the data disk to a VM that was added to a separately created cloud service ("hosted service"). But If you create a VM without creating a separate cloud service first, the add-disk on that VM works. Details are as follows:

When we create a VM without creating a separate cloud service first, 3 things get created (in addition to the VM itself):
(a) A cloud service by the same name as the VM
(b) A "deployment" by the same name as the VM
(c) A "role" as the same name as the VM

Now, The function resourceAzureDataDiskCreate(...) in resource_azure_data_disk.go calls AddDataDisk(...), which is defined here: https://github.com/Azure/azure-sdk-for-go/blob/master/management/virtualmachinedisk/client.go

During that call, it passes the same VM name as 'service', 'deployment' and 'role' parameters. Hence, that piece of code is written assuming that the add-data-disk functionality will always be called upon VM-s which are part of a cloud service by the same name, deployment by the same name and role by the same name (which is the case for VM-s that are created WITHOUT creating a separate cloud service first).

Thus, how to resolve this issue? One easy way is to expand the resource parameters for "azure_data_disk" resource to include (optional) cloud service name, deployment name and role name. Actually, the role name is not needed, as the role name is always the same as the virtual machine name in both methods of instance creation. It may be a good practice, however, to have role name as parameter just to avoid similar situations down the line.

Thus, this problem can be solved inside terraform code (as opposed to waiting for azure-sdk-for-go to be fixed first).

But again, unless this bug gets fixed first (#3568) - just fixing the data disk issue won't buy us much.

[kbxkb]

Update - this bug is now fixed on my fork (https://github.com/kbxkb/terraform) (see last two commits above). @rksinghal please feel free to test. You will need corresponding changes in azure-sdk-for-go to compile, see below.

Will submit pull request on master after this pull request on azure-sdk-for-go is accepted: Azure/azure-sdk-for-go#238

[davehodgson]

Sorry for an ill informed question @kbxkb I have the same problem with a script just now and updated to the most recent version 0.6.8 of terraform. I haven't got a dev environment set up to build (or probably the expertise to build it correctly).

How does the process work for your fix to be incorporated into the release and any eta for when it happens?

[kbxkb]

@davehodgson as far as steps to set up a dev environment for building, you can follow the step by step guide I have in the README.md file on my terraform starter repo: https://github.com/kbxkb/provision-azure-with-terraform. Follow the README, and you should be able to set everything up easily.

My fix for this bug will not be incorporated into the official release unless I submit a pull request and it gets reviewed and accepted.

I am unable to do that unless my changes to underlying "azure-sdk-for-go" repository are accepted, because the fix to this bug in terraform depends on those fixes in azure-sdk-for-go. I have already submitted a pull request for those changes, here: Azure/azure-sdk-for-go#238

Once that is accepted, I will then submit a pull request for my fixes in the terraform repository.

In the meantime, if you plan to use my fix, you have to do the following:

1. set your dev environment up to build terraform (following steps on https://github.com/kbxkb/provision-azure-with-terraform)
2. apply the changes to azure-sdk-for-go code from this pull request: Add query parameter to DeleteRole to delete disk based on boolean Azure/azure-sdk-for-go#238. Should be easy as it is only in 1 file
3. apply my changes for this bug. this will be a little more difficult, but possible. As my fork (https://github.com/kbxkb/terraform) has the fix, and the fix spans the last 6 commits, you can use the git compare function to generate a diff from those 6 commits, and apply them to your codebase. Here is a link that generates that diff: master...kbxkb:master

Thanks, hope this helps!

[kbxkb]

@davehodgson good news! My changes for azure-sdk-for-go (Azure/azure-sdk-for-go#238) have been accepted and merged. Consequently, I have created a pull request on Terraform to address this specific bug (and another bug as well). Here is the pull request: #4199

So keep an eye on the pull request. Terraform master will have this fix as soon as it is accepted and merged! Thanks!

[kbxkb]

Update: A fix for this bug is awaiting to be reviewed, accepted and merged: #4199

[davehodgson]

@kbxkb great news, thanls for the update. I had it on my list for later in the week so I'll just watch the pull. Thanks again for sorting it out

[ghost]

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.