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

Azure virtual machine interfaces are not being created and attached in the order they are defined within the main.tf script #15153

Closed
kblackstone opened this issue Jun 7, 2017 · 2 comments

Comments

@kblackstone
Copy link

Terraform Version

0.9.6

Affected Resource(s)

  • azurerm_network_interface
  • azurerm_virtual_machine

Terraform Configuration Files

https://www.dropbox.com/s/q4pnvy0bs2812vk/main.tf?dl=0

Expected Behavior

The interfaces should be consistently created and attached in the following order: management, untrust, trust as defined within the main.tf script.

Actual Behavior

Terraform plan is showing they will be attached in this order: management, trust, untrust. This is the actual order they get attached in on the virtual machine when launched via terraform apply, which is incorrect. The attachment order is inconsistent. On one run of terraform plan/apply it may create in the right order, on another run of terraform plan/apply it will be in the incorrect order. The first interface is ok due to primary_network_interface_id. I have screen shots of desired.

Steps to Reproduce

  1. terraform plan
  2. terraform apply
@kblackstone kblackstone changed the title Interfaces are not being created and attached in the order they are defined within the main.tf script Azure virtual machine interfaces are not being created and attached in the order they are defined within the main.tf script Jun 7, 2017
@pearcec
Copy link
Contributor

pearcec commented Jun 7, 2017

The first step we need to take is to determine if the ordering of the list is getting changed in terraform or in the go-sdk.

@ghost
Copy link

ghost commented Apr 9, 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 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.

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

No branches or pull requests

4 participants