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

"wait_for_ips" not being respected #186

Closed
mattgagliardi opened this issue Feb 7, 2023 · 4 comments
Closed

"wait_for_ips" not being respected #186

mattgagliardi opened this issue Feb 7, 2023 · 4 comments

Comments

@mattgagliardi
Copy link

mattgagliardi commented Feb 7, 2023

Hi there,

Thank you for opening an issue. Please note that we try to keep the Terraform issue tracker reserved for bug reports and feature requests. For general usage questions, please see: https://www.terraform.io/community.html.

Terraform Version

Terraform v1.3.7

Hyper-V Provider Version

1.0.4

Affected Resource(s)

Please list the resources as a list, for example:

  • hyperv_machine_instance

Terraform Configuration Files

### The material bits would seem to be the following. ###
# Create a machine
resource "hyperv_machine_instance" "demo" {
  name                                    = "Demo"
  generation                              = 1
  automatic_critical_error_action         = "Pause"
  automatic_critical_error_action_timeout = 30
  automatic_start_action                  = "Nothing"
  automatic_start_delay                   = 0
  automatic_stop_action                   = "ShutDown"
  checkpoint_type                         = "Production"
  high_memory_mapped_io_space             = 536870912
  low_memory_mapped_io_space              = 134217728
  memory_maximum_bytes                    = 6442450944
  memory_minimum_bytes                    = 536870912
  memory_startup_bytes                    = 6442450944
  notes                                   = "This is a test"
  processor_count                         = 4
  smart_paging_file_path                  = "C:\\ProgramData\\Microsoft\\Windows\\Hyper-V"
  snapshot_file_location                  = "C:\\ProgramData\\Microsoft\\Windows\\Hyper-V"
  dynamic_memory                          = true
  state                                   = "Running"
  wait_for_ips_poll_period                = 5
  wait_for_ips_timeout                    = 999
  wait_for_state_poll_period              = 300
  wait_for_state_timeout                  = 999
...
  # Create a network adaptor
  network_adaptors {
    name                                       = "wan"
    switch_name                                = "External"
    management_os                              = false
    is_legacy                                  = false
    dynamic_mac_address                        = false
    static_mac_address                         = "00155D000001"
    virtual_subnet_id                          = 0
    wait_for_ips                               = true
  }
...
output "ip_v4_address" {
  value = resource.hyperv_machine_instance.demo.network_adaptors[0].ip_addresses.0
  }

Debug Output

Debug output here

Panic Output

  • NA

Expected Behavior

My expectation is the provider will wait for the net adaptor to be assigned an IP address before concluding.

Actual Behavior

Rather than wait up until the "wait_for_ips" timeout the provider seems to view the successful start of the VM (into "running" state) as the trigger to conclude. As such my output variable isn't being populated.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

  1. terraform apply
  2. Wait.

Important Factoids

Nothing I can think of. This is all very vanilla.

References

  • None
@mattgagliardi
Copy link
Author

I think what I may be after here is a way to tell the provider to not evaluate the machine as up/down for a specified period of time. I think what may be happening is there’s an up/down evaluation taking place before the polling interval and timeout take effect (as in make an initial check and if it’s not up yet go into the internal/timeout). But that’s just speculation on my part.

@mattgagliardi
Copy link
Author

I had the chance to look closer and see more of what's happening. The machine I'm deploying is being spun out of a "golden" Windows template, one that's been properly SysPrep'd, etc. When it's powered up for the first time it has to go through SysPrep-related activities for about a minute (in the background), then it reboots and when it comes back up it's ready for use and is unique from any other machines created from the image. It's the automatic post-SysPrep reboot that's causing problems. The provider seems to be interpreting that as everything being ready...the problem is that no IP address has been assigned yet (it takes another few seconds)...which means it's not there to be referenced by later portions of my TF plan. My interpretation of the "wait_for_ips" options was that they'd be the controlling factor in whether or not the provider would proceed...but that does not appear to be happening. Any suggestions?

@taliesins
Copy link
Owner

The terraform provider reports the ip address allocated to the vm.

More than likely you probably want to leverage another mechanism like Packer does. Packer will poll WinRM or SSH port until it can make a successful connection. So during the creation of the golden image ensure that WinRM/SSH is not running or firewall is blocking it and as the last step of the sysprep enable it.

Hopefully I can figure out how to add a cloud-init/user-data equivalent (e.g. create iso and hook it up), then issues like this will go away. See #36

@taliesins
Copy link
Owner

I have merged in the ability to add custom ISOs. Which I think enabled the ability to solve the problem. Lets continue the conversation on #36

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants