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

New Resource: azurerm_virtual_machine_data_disk_attachment #1207

Merged
merged 12 commits into from
Jun 27, 2018

Conversation

tombuildsstuff
Copy link
Contributor

@tombuildsstuff tombuildsstuff commented May 6, 2018

This PR creates a new resource which can be used for attaching disks to Virtual Machine. The acceptance tests for this need some more thought and this needs some extensive testing, in general.

After spending a lot of time investigating/thinking about this - I've ended up adapting this resource such that it only supports attaching existing Managed Disks. This makes supporting this resource considerably simpler (since supporting creating new Managed Disks involves manipulating the create_option field); unfortunately it appears this approach isn't possible for Unmanaged Disks due to this bug - as such I've dropped support for Unmanaged Disks at this time.

Fixes #795

@amcguign
Copy link

amcguign commented May 6, 2018

Great to see this - thanks @tombuildsstuff ! 👍

@metacpp metacpp self-requested a review May 6, 2018 23:23
"azurerm_virtual_network_gateway": resourceArmVirtualNetworkGateway(),
"azurerm_virtual_network_gateway_connection": resourceArmVirtualNetworkGatewayConnection(),
"azurerm_virtual_network_peering": resourceArmVirtualNetworkPeering(),
"azurerm_application_gateway": resourceArmApplicationGateway(),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why did you change so many lines?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because one space is added to align with each other.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

on that note: you can use ?w=1 to ignore whitespace changes in reviews in Github, it's really handy for things like this :)

metacpp
metacpp previously requested changes May 6, 2018
dataDisks := make([]compute.DataDisk, 0)
for _, dataDisk := range disks {
if !strings.EqualFold(*dataDisk.Name, *expandedDisk.Name) {
disks = append(disks, dataDisk)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems that dataDisks is never used since initialization. I guess you were using it store the left disks. Then I think you should do:

dataDisks = append(dataDisks, dataDisk)

Copy link

@JunyiYi JunyiYi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have some concerns of introducing multiples ways to do one thing. It might cause updating issues similar to azurerm_network_security_rule.

We need to carefully think of it if we are not able to mitigate this kind of thing.

azurerm/disks.go Outdated
"strings"
)

type UnmanagedDiskMetadata struct {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any rules on custom types, like should it always be public, and the naming convention?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

they should be private, however this is a WIP before refactoring (and placing this somewhere in helpers/)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(also, we tend to rely directly on the SDK Structs rather than composing them ourselves, since this is information which should be provided by the SDK but isn't at this point)

"azurerm_virtual_network_gateway": resourceArmVirtualNetworkGateway(),
"azurerm_virtual_network_gateway_connection": resourceArmVirtualNetworkGatewayConnection(),
"azurerm_virtual_network_peering": resourceArmVirtualNetworkPeering(),
"azurerm_application_gateway": resourceArmApplicationGateway(),
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because one space is added to align with each other.

@tombuildsstuff
Copy link
Contributor Author

I have some concerns of introducing multiples ways to do one thing. It might cause updating issues similar to azurerm_network_security_rule.

@JunyiYi indeed, this is why this is still WIP whilst I've been thinking about how's best to implement this/chatting internally about it. We should be keeping both resources actually - the nested resource is beneficial as it allows the user to explicitly say "I only want these disks attached" vs the attachment resource for "I'm not concerned with what other disks are attached, just attach this given disk".

After mulling on this for a while, I'm coming around to the idea of forcing users to create a separate managed disk ahead of time, which allows us to remove the create_option field altogether (which is a huge pain-point), and also handles disk cleanup (by the azurerm_managed_disk resource being deleted); which would allow us to infer the details from the disk, making the attachment resource look something like this:

resource "azurerm_managed_disk" "test" {
  name                 = "tomdev-disk25"
  location             = "${azurerm_resource_group.test.location}"
  resource_group_name  = "${azurerm_resource_group.test.name}"
  storage_account_type = "Standard_LRS"
  create_option        = "Empty"
  disk_size_gb         = 10
}

resource "azurerm_virtual_machine_data_disk_attachment" "second" {
  name               = "some-name" # perhaps we could infer this from the Disk Name?
  virtual_machine_id = "${azurerm_virtual_machine.windows.id}"
  managed_disk_id    = "${azurerm_managed_disk.test.id}"
  lun                = 33
  caching            = "ReadOnly"
}

rather than this:

resource "azurerm_managed_disk" "test" {
  name                 = "tomdev-disk25"
  location             = "${azurerm_resource_group.test.location}"
  resource_group_name  = "${azurerm_resource_group.test.name}"
  storage_account_type = "Standard_LRS"
  create_option        = "Empty"
  disk_size_gb         = 10
}

resource "azurerm_virtual_machine_data_disk_attachment" "existing_disk" {
  name               = "existing-disk"
  virtual_machine_id = "${azurerm_virtual_machine.windows.id}"
  managed_disk_id    = "${azurerm_managed_disk.test.id}"
  managed_disk_type  = "Standard_LRS"
  disk_size_gb       = "${azurerm_managed_disk.test.disk_size_gb}"
  lun                = 33
}

The outstanding question is how we'd achieve the same thing with unmanaged disks, which I'm looking into at the moment :)

@tombuildsstuff tombuildsstuff force-pushed the vm-data-disk-attachment branch from 07fd1ab to ca4b335 Compare May 31, 2018 15:33
@tombuildsstuff tombuildsstuff dismissed stale reviews from metacpp and JunyiYi May 31, 2018 15:36

dismissing stale review

@tombuildsstuff tombuildsstuff force-pushed the vm-data-disk-attachment branch 2 times, most recently from 46c0f7c to bf3598b Compare May 31, 2018 17:43
@rohrerb
Copy link
Contributor

rohrerb commented Jun 1, 2018

Excited to see this merged. :D

@tombuildsstuff tombuildsstuff changed the title [WIP] New Resource: azurerm_virtual_machine_data_disk_attachment New Resource: azurerm_virtual_machine_data_disk_attachment Jun 1, 2018
@tombuildsstuff tombuildsstuff changed the title New Resource: azurerm_virtual_machine_data_disk_attachment [WIP] New Resource: azurerm_virtual_machine_data_disk_attachment Jun 1, 2018
@tombuildsstuff
Copy link
Contributor Author

I've been doing some initial exploratory testing against this and it seems ok, but it needs some more (in particular verifying disks created inline -> split out are handled as expected, which I'll pick up when I'm back). I've also pushed a WIP commit which should prevent disk attachments created using the independent resource from being impacted when changes are made to the parent VM resource which uses the value of the computed fields, but this needs additional testing.

@rohrerb
Copy link
Contributor

rohrerb commented Jun 18, 2018

Hi @tombuildsstuff ,

Any chance this will get merged soon? Need any help testing?

-Brandon

@tombuildsstuff
Copy link
Contributor Author

👋 @rohrerb I've been out for a couple of weeks, so I've not been working on this; but I'm working through the edge-case testing at the moment and hope to finish that this week. That said - we're definitely interested to hear your feedback if you're able to test this :)

Thanks!

@tombuildsstuff tombuildsstuff removed this from the Soon milestone Jun 19, 2018
@tombuildsstuff tombuildsstuff added this to the 1.8.0 milestone Jun 19, 2018
@tombuildsstuff tombuildsstuff force-pushed the vm-data-disk-attachment branch from d239408 to 32953a0 Compare June 20, 2018 12:51
@tombuildsstuff tombuildsstuff changed the title [WIP] New Resource: azurerm_virtual_machine_data_disk_attachment New Resource: azurerm_virtual_machine_data_disk_attachment Jun 20, 2018
@tombuildsstuff tombuildsstuff requested a review from a team June 20, 2018 13:23
Copy link
Collaborator

@katbyte katbyte left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @tombuildsstuff,

Outside a couple minor comments this LGTM 👍

Required: true,
ForceNew: true,
DiffSuppressFunc: ignoreCaseDiffSuppressFunc,
},
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could be validated with validate.ValidateResourceId


dataDisks := make([]compute.DataDisk, 0)
for _, dataDisk := range *virtualMachine.StorageProfile.DataDisks {
// since this field isn't (and shouldn't be) case-sensitive; we're deliberately not using `strings.Equals`
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you mean strings.EqualFold()

@@ -1,7 +1,7 @@
---
layout: "azurerm"
page_title: "Azure Resource Manager: azurerm_virtual_machine"
sidebar_current: "docs-azurerm-resource-compute-virtual-machine"
sidebar_current: "docs-azurerm-resource-compute-virtual-machine-x"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was the -x supposed to be added?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, there's an incorrect highlight on the sidebar at the moment

@tombuildsstuff tombuildsstuff force-pushed the vm-data-disk-attachment branch from 92c522e to ab9171f Compare June 27, 2018 07:35
@tombuildsstuff tombuildsstuff merged commit 10af28f into master Jun 27, 2018
@tombuildsstuff tombuildsstuff deleted the vm-data-disk-attachment branch June 27, 2018 08:40
tombuildsstuff added a commit that referenced this pull request Jun 27, 2018
@ghost
Copy link

ghost commented Mar 30, 2020

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!

@ghost ghost locked and limited conversation to collaborators Mar 30, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Feature Request: new resource to attach disks to virtual machines
7 participants