Provisioner remote-exec power-shell restart and continue

[Raviadonis]

Hello there!,

We are running a power-shell script with remote-exec provisioner, which has few set of commands to execute initially and restart the computer and execute another set of commands. But during terraform apply it fails with executing only the initial commands and restarting the computer and interrupted finally.

Is there a way we can achieve this from terraform end?

###Terraform Configuration

# Instance provisioner

resource "openstack_compute_instance_v2" "provisioner_node" {
  name              = "windows-provisioner"
  count             = "1"
  image_id          = "2cf4c1aa-7ec3-xxxx-xxxx-xxxxxxxxxxxx"
  flavor_name       = "m1.small"
  key_pair          = "xxxx"
  availability_zone = "xxxx"
  security_groups   = ["xxxx"]
  network {
    name = "xxxx"
  }
}

resource "null_resource" "cluster" {
  depends_on = ["openstack_compute_instance_v2.provisioner_node"]

  provisioner "file" {
    source      = "sample_script"
    destination = "C:/xxxx/script.ps1"
  }

  connection {
    host        = "${openstack_compute_instance_v2.provisioner_node.access_ip_v4}"
    type        = "winrm"
    user        = "xxxx"
    password    = "xxxx"
  }

  provisioner "remote-exec" {
    inline = ["powershell C:/xxxx/script.ps1"]
  }
}

###Sample Script

mkdir beforereboot
Start-Sleep 30
Restart-Computer
Start-Sleep 120
mkdir afterreboot

###Output log

openstack_compute_instance_v2.provisioner_node: Creating...
  access_ip_v4:               "" => "<computed>"
  access_ip_v6:               "" => "<computed>"
  all_metadata.%:             "" => "<computed>"
  availability_zone:          "" => "Testing"
  flavor_id:                  "" => "<computed>"
  flavor_name:                "" => "m1.small"
  force_delete:               "" => "false"
  image_id:                   "" => "2cf4c1aa-7ec3-xxxx-xxxx-xxxxxxxxxxxx"
  image_name:                 "" => "<computed>"
  key_pair:                   "" => "xxxxxx"
  name:                       "" => "windows-provisioner"
  network.#:                  "" => "1"
  network.0.access_network:   "" => "false"
  network.0.fixed_ip_v4:      "" => "<computed>"
  network.0.fixed_ip_v6:      "" => "<computed>"
  network.0.floating_ip:      "" => "<computed>"
  network.0.mac:              "" => "<computed>"
  network.0.name:             "" => "xxxx"
  network.0.port:             "" => "<computed>"
  network.0.uuid:             "" => "<computed>"
  region:                     "" => "<computed>"
  security_groups.#:          "" => "1"
  security_groups.3814588639: "" => "default"
  stop_before_destroy:        "" => "false"
openstack_compute_instance_v2.provisioner_node: Still creating... (10s elapsed)
openstack_compute_instance_v2.provisioner_node: Creation complete after 17s (ID: 7b8c0f69-0c3a-xxxx-xxxx-xxxxxxxxxx)
null_resource.cluster: Creating...
null_resource.cluster: Provisioning with 'file'...
null_resource.cluster: Still creating... (10s elapsed)
null_resource.cluster: Still creating... (20s elapsed)
null_resource.cluster: Still creating... (30s elapsed)
null_resource.cluster: Still creating... (40s elapsed)
null_resource.cluster: Provisioning with 'remote-exec'...
null_resource.cluster (remote-exec): Connecting to remote host via WinRM...
null_resource.cluster (remote-exec):   Host: 10.x.x.x
null_resource.cluster (remote-exec):   Port: 5985
null_resource.cluster (remote-exec):   User: xxxxx
null_resource.cluster (remote-exec):   Password: true
null_resource.cluster (remote-exec):   HTTPS: false
null_resource.cluster (remote-exec):   Insecure: false
null_resource.cluster (remote-exec):   NTLM: false
null_resource.cluster (remote-exec):   CACert: false
null_resource.cluster (remote-exec): Connected!

null_resource.cluster (remote-exec): C:\Users\xxxxxxx>powershell C:/xxxxxx/script.ps1
null_resource.cluster: Still creating... (50s elapsed)


null_resource.cluster (remote-exec):     Directory: C:\Users\xxxx


null_resource.cluster (remote-exec): Mode                LastWriteTime         Length Name
null_resource.cluster (remote-exec): ----                -------------         ------ ----
null_resource.cluster (remote-exec): d-----       2019/07/29     15:05                beforereboot
null_resource.cluster: Still creating... (1m0s elapsed)
null_resource.cluster: Still creating... (1m10s elapsed)
null_resource.cluster: Still creating... (1m20s elapsed)
null_resource.cluster: Still creating... (1m30s elapsed)
null_resource.cluster: Still creating... (1m40s elapsed)
null_resource.cluster: Still creating... (1m50s elapsed)

Error: Error applying plan:

1 error(s) occurred:

* null_resource.cluster: error executing "C:/Temp/terraform_1735854571.cmd": unknown error Post http://10.x.x.x:5985/wsman: read tcp 10.x.x.x:44938->10.x.x.x:5985: read: connection reset by peer

Terraform does not automatically rollback in the face of errors.
Instead, your Terraform state file has been partially updated with
any resources that successfully completed. Please address the error
above and apply again to incrementally change your infrastructure.

###References
-#17844

[Prabhakar-cg]

will it work if we split this into two provisioners(till reboot first provisioner & post reboot second provisioner will handle the rest of the script).
For suppressing the "connection reset" error during the reboot(first provisioner), may be we can use 'allow_missing_exit_status = true' parameter to ignore the error and continue with next provisioner.
New provisioner connection will try for few minutes before getting timeout(hope windows will boot before provisioner timeout)

[hashibot]

Hello! 🤖

We use GitHub issues for tracking bugs and enhancements rather than for questions. While we can sometimes help with certain simple problems here, it's better to use the community forum where there are more people ready to help. The GitHub issues here are monitored only by our few core maintainers.

Since this issue doesn't represent a specific bug or feature request, I'm going to close it. Please do feel free to ask your question in the community forum. Thanks!

[ghost]

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.