Terraform fails to create vm if wireguard access = true

[s-areal]

I tried many times to create vms using terraform, and all failed. Tested on different nodes, differente configurations, different days.... My conclusion is that if using wireguard access = true it will not work!

[A-Harby]

I tried deploying a vm and taiga on two networks and it worked fine

I was using version 1.9.3-rc1. Maybe you could provide more info on your version, networks, logs, and maybe the script you are trying to use.

[s-areal]

I'm using 1.9.2, I didn't know there was a 1.9.3-rc1. Anyway I upgraded to 1.9.3-rc1 and the problem is exactly the same.

Version 1.9.3-rc1 with add_wg_access = true

grid_network.netteste_3021 will be created

• resource "grid_network" "netteste_3021" {
  • access_wg_config = (known after apply)
  • add_wg_access = true
  • description = "SomeNetwork"
  • external_ip = (known after apply)
  • external_sk = (known after apply)
  • id = (known after apply)
  • ip_range = "10.32.0.0/16"
  • name = "netteste_3021"
  • node_deployment_id = (known after apply)
  • nodes = [
    • 3021, ]
  • nodes_ip_range = (known after apply)
  • public_node_id = (known after apply)
  • solution_type = "Network" }

Plan: 2 to add, 0 to change, 0 to destroy.

Changes to Outputs:

• ygg_ip_3021 = (known after apply) grid_network.netteste_3021: Creating... grid_network.netteste_3021: Still creating... [10s elapsed] grid_network.netteste_3021: Still creating... [20s elapsed] ╷ │ Error: could not generate deployments data: failed to get node 1 endpoint: could not list node interfaces: context deadline exceeded

Version 1.9.3-rc1 with add_wg_access = false

grid_network.netteste_3021 will be created

• resource "grid_network" "netteste_3021" {
  • access_wg_config = (known after apply)
  • add_wg_access = false
  • description = "SomeNetwork"
  • external_ip = (known after apply)
  • external_sk = (known after apply)
  • id = (known after apply)
  • ip_range = "10.32.0.0/16"
  • name = "netteste_3021"
  • node_deployment_id = (known after apply)
  • nodes = [
    • 3021, ]
  • nodes_ip_range = (known after apply)
  • public_node_id = (known after apply)
  • solution_type = "Network" }

Plan: 2 to add, 0 to change, 0 to destroy.

Changes to Outputs:

• ygg_ip_3021 = (known after apply) grid_network.netteste_3021: Creating... grid_network.netteste_3021: Creation complete after 6s [id=a204ee8d-d755-475d-bb2b-e9e88b3543b5] grid_deployment._3021: Creating... grid_deployment._3021: Still creating... [10s elapsed] grid_deployment._3021: Creation complete after 11s [id=94036]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

[A-Harby]

╷ │ Error: could not generate deployments data: failed to get node 1 endpoint: could not list node interfaces: context deadline exceeded

The error appears to be from node 1, not the wireguard. You could specify a node ID in both the network and the VM for another node ID and try again.

I checked node 1, and it does have a problem responding over RMB.

[AbdelrahmanElawady]

It turned the issue is caused by some nodes appearing as "Up" while they actually don't respond to RMB calls. So, in case of wireguard access = true, the deployer looks for a public node that is up and try to include it with the deployment (that's why node 1 in your case appeared while you didn't choose it). We added some extra checks to make sure the nodes chosen as access nodes are actually up and respond to RMB calls. The fix should be on it's way in the upcoming mainnet release.

[rawdaGastan]

Verified using version 1.9.3-rc2. Will be available in the next release 1.9.3

Tried the multinode example (https://github.com/threefoldtech/terraform-provider-grid/tree/development/examples/resources/multinode)

It uses WireGuard and it worked fine