-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Conversation
Fixes a deadlock issue for multiple Subnets in the same Virtual Network
azurerm_network_interface
- support for multiple IP Configurations / setting the primaryazurerm_network_interface
- support for multiple IP Configurations / setting the primary
Great work, I have been looking forward for the primary ip_configuration feature. |
There was a problem hiding this 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{}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could this cast panic?
There was a problem hiding this 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) |
There was a problem hiding this comment.
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, |
There was a problem hiding this comment.
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 🤔
There was a problem hiding this comment.
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{}) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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 firstip_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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 🙂
There was a problem hiding this 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)
3161160
to
22c2379
Compare
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! |
ip_configuration
from a Set -> Listip_configuration
. Migrated across provider/azurerm: suppport for primary network interface terraform#12277network_security_group_id
. Fixes Terraform does not change security group of network interface on Azure #60ip_configurations
. Fixes Enhancement: Allow more than one IP Configuration on azurerm_network_interface #26 & a deadlock issue