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

azurerm_network_interface - support for multiple IP Configurations / setting the primary #245

Merged
merged 13 commits into from
Aug 17, 2017

Conversation

tombuildsstuff
Copy link
Contributor

@tombuildsstuff tombuildsstuff commented Aug 15, 2017

@tombuildsstuff tombuildsstuff changed the title [WIP] azurerm_network_interface - support for multiple IP Configurations / setting the primary azurerm_network_interface - support for multiple IP Configurations / setting the primary Aug 15, 2017
@dominik-lekse
Copy link
Contributor

Great work, I have been looking forward for the primary ip_configuration feature.

@tombuildsstuff tombuildsstuff requested review from radeksimko and removed request for grubernaut August 16, 2017 10:04
Copy link
Contributor

@grubernaut grubernaut left a comment

Choose a reason for hiding this comment

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

LGTM, minor question

@@ -356,7 +362,7 @@ func resourceArmNetworkInterfaceDelete(d *schema.ResourceData, meta interface{})
defer azureRMUnlockByName(networkSecurityGroupName, networkSecurityGroupResourceName)
}

configs := d.Get("ip_configuration").(*schema.Set).List()
configs := d.Get("ip_configuration").([]interface{})
Copy link
Contributor

Choose a reason for hiding this comment

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

could this cast panic?

Copy link
Member

@radeksimko radeksimko left a comment

Choose a reason for hiding this comment

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

I left you some comments/questions there - the most important one is regarding state migration.

if *iface.VirtualMachine.ID != "" {
d.Set("virtual_machine_id", *iface.VirtualMachine.ID)
}
d.Set("virtual_machine_id", *iface.VirtualMachine.ID)
Copy link
Member

Choose a reason for hiding this comment

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

I think you can omit the * here to prevent potential crashes?

"virtual_machine_id": {
Type: schema.TypeString,
Optional: true,
Computed: true,
},

"ip_configuration": {
Type: schema.TypeSet,
Type: schema.TypeList,
Copy link
Member

Choose a reason for hiding this comment

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

Are you sure this doesn't require state migration? It's the most common example for migration, IMO 🤔

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I tested with a resource/state created on master -> this branch and apparently not ¯_(ツ)_/¯

@@ -356,7 +362,7 @@ func resourceArmNetworkInterfaceDelete(d *schema.ResourceData, meta interface{})
defer azureRMUnlockByName(networkSecurityGroupName, networkSecurityGroupResourceName)
}

configs := d.Get("ip_configuration").(*schema.Set).List()
configs := d.Get("ip_configuration").([]interface{})
Copy link
Member

Choose a reason for hiding this comment

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

Correct me if I'm wrong, but I think this will crash with the old state (with Set) without migration.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I may have tested something wrong, but this appeared to be fine when testing the migration from a resource/state created with master?

rInt := acctest.RandInt()
location := testLocation()
config := testAccAzureRMNetworkInterface_basicWithNetworkSecurityGroup(rInt, location)
updatedConfig := testAccAzureRMNetworkInterface_basic(rInt, location)
Copy link
Member

Choose a reason for hiding this comment

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

Nitpick, but I think config & updatedConfig don't need to be variables for that single purpose a few lines below. 🙂

@@ -91,11 +92,13 @@ The `ip_configuration` block supports:

* `load_balancer_inbound_nat_rules_ids` - (Optional) List of Load Balancer Inbound Nat Rules IDs involving this NIC

* `primary` - (Optional) Is this the Primary Network Interface? If set to `true` this should be the first `ip_configuration` in the array.
Copy link
Member

Choose a reason for hiding this comment

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

If set to true this should be the first ip_configuration in the array

This feels a little bit unintuitive for the user - is it because the API requires it? Can't we just sort it for the user prior to sending the request to the API?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

so, the user can submit the second (or later) ip_configuration as primary and that'll update but lead to a perpetual diff, as it's returned first in the response; we could probably do something there, but this mirrors the UI

The alternative I considered here was just assuming the first would be the primary, but that may not necessarily be optimal? WDYT?

Copy link
Member

Choose a reason for hiding this comment

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

The alternative I considered here was just assuming the first would be the primary

Hm, I think making assumptions is probably even worse UX. This is at the very least explicit. So if you think it's ok then go ahead - I just thought as a user I'd be little bit annoyed or confused 🙂

Copy link
Member

@radeksimko radeksimko left a comment

Choose a reason for hiding this comment

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

As discussed via Slack - this doesn't require migration. (TIL)

@tombuildsstuff
Copy link
Contributor Author

Tests pass:
screen shot 2017-08-17 at 13 55 15

@tombuildsstuff tombuildsstuff merged commit fc06f59 into master Aug 17, 2017
@tombuildsstuff tombuildsstuff deleted the primary-nic branch August 17, 2017 12:00
tombuildsstuff added a commit that referenced this pull request Aug 17, 2017
tombuildsstuff added a commit that referenced this pull request Aug 17, 2017
@ghost
Copy link

ghost commented Apr 1, 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 👉 hashibot-feedback@hashicorp.com. Thanks!

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