vultr / terraform-provider-vultr-community Goto Github PK

Using terrform-provider-vultr built from latest main branch and Terraform 0.12

$ terraform --version
Terraform v0.12.3
+ provider.vultr (unversioned)

The vultr_firewall_rule example here shows the protocol is set with a name

resource "vultr_firewall_rule" "my_firewallrule" {
    firewall_group_id = "${vultr_firewall_group.my_firewallgroup.id}"
    protocol = "TCP"
    network = "0.0.0.0/0"
    from_port = "8085"
    to_port = "8090"
}

But applying a config with a vultr_firewall_rule returns an error that the protocol should be a number. e.g

vultr_firewall_rule.ssh: Creating...

Error: Err creating firewall group : Unable to add rule: Invalid protocol (must be one of 1, 6, 17, 47, 50)

  on firewall.tf line 10, in resource "vultr_firewall_rule" "ssh":
  10: resource vultr_firewall_rule ssh {

Changing the protocol to a number (e.g. 6 for TCP) doesn't work as the apply is passing the number as a string with Terraform 0.12

Terraform will perform the following actions:

  # vultr_firewall_rule.ssh will be created
  + resource "vultr_firewall_rule" "ssh" {
      + firewall_group_id = "70d64090"
      + from_port         = 22
      + id                = (known after apply)
      + ip_type           = (known after apply)
      + network           = "0.0.0.0/0"
      + protocol          = "6"
      + to_port           = 22
    }

Describe the bug
I think file provisioner is not working correctly.
When I was on #87 , my file didn't appear on my remote host.

To Reproduce

# please apply this file to test
# common.sh originally was filled with kubectl, kubeadm and kubelet install commands.
# I failed again with common.sh replaced with echo '123'.
provider "vultr" {}
data "vultr_os" "coreos" {
  filter {
    name   = "family"
    values = ["coreos"]
  }
}
data "vultr_plan" "plan_1c2g" {
  filter {
    name   = "VPSPLANID"
    values = ["202"]
  }
}

data "vultr_plan" "plan_2c4g" {
  filter {
    name   = "VPSPLANID"
    values = ["203"]
  }
}

data "vultr_region" "tokyo" {
  filter {
    name   = "name"
    values = ["Tokyo"]
  }
}

resource "vultr_server" "master_standalone" {
	plan_id = "${data.vultr_plan.plan_2c4g.id}"
	region_id = "${data.vultr_region.tokyo.id}"
	os_id = "${data.vultr_os.coreos.id}"
	hostname = "master-01"
	provisioner "file" {
    source      = "common.sh"
    destination = "/tmp/common.sh"
  }
  provisioner "remote-exec" {
    inline = [
      "chmod +x /tmp/common.sh"
    ]
  }
}

Expected behavior

1. timeout from client side
2. no such file '/tmp/common.sh'

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information where applicable:

• OS: CentOS 7 GNOME desktop, 3.10.0-957.21.3.el7.x86_64
• Language Version : Go 1.12.7

Additional context

Add any other context about the problem here.

When adding a remote-exec to a config it's acutally executed on the localhost as the host field is not populated:

resource "vultr_server" "this" {
  label       = var.server_name
  plan_id     = "${data.vultr_plan.starter.id}"
  os_id       = "${data.vultr_os.ubuntu-1904.id}"
  region_id   = "${data.vultr_region.sydney.id}"
  ssh_key_ids = var.ssh_key_ids
  provisioner "remote-exec" {
    inline     = [
      "apt update",
      "apt -y dist-upgrade",
    ]
  }
}

Some output:

module.vultr_server_testypants2.vultr_server.this: Still creating... [1m30s elapsed]
module.vultr_server_testypants1.vultr_server.this: Still creating... [1m30s elapsed]
module.vultr_server_testypants2.vultr_server.this: Provisioning with 'remote-exec'...
module.vultr_server_testypants2.vultr_server.this (remote-exec): Connecting to remote host via SSH...
module.vultr_server_testypants2.vultr_server.this (remote-exec):   Host:
module.vultr_server_testypants2.vultr_server.this (remote-exec):   User: root
module.vultr_server_testypants2.vultr_server.this (remote-exec):   Password: false
module.vultr_server_testypants2.vultr_server.this (remote-exec):   Private key: false
module.vultr_server_testypants2.vultr_server.this (remote-exec):   Certificate: false
module.vultr_server_testypants2.vultr_server.this (remote-exec):   SSH Agent: true
module.vultr_server_testypants2.vultr_server.this (remote-exec):   Checking Host Key: false
module.vultr_server_testypants2.vultr_server.this (remote-exec): Connected!
module.vultr_server_testypants2.vultr_server.this (remote-exec): 
module.vultr_server_testypants2.vultr_server.this (remote-exec): 0% [Working]

The reason it shows connected there is because I can SSH to my localhost.

Describe the bug
It seems I've been playing with this provider enough to get rate-limited, and so now I can't plan/refresh at all because it hits the API faster than the hard rate-limit allows.

Error: Error getting : Rate limit reached - please try your request again later. Current rate limit: 3 requests/sec

To Reproduce
Steps to reproduce the behavior:

1. Create >N Vultr resources
2. terraform apply
3. Get rate-limited to N requests/sec
4. terraform refresh

Expected behavior
Detects the limit and backs off maybe?

Additional context

I haven't been using it that much!

Thanks for your all great work so that I can use terraform on Vultr!

General behavior for most providers, "data" can list all the data. e.g. data "xxx_region" "regions" {} will return all available regions.

But in Vultr provider, we have to add filter to it. Which means I can not setup up a generic step in the flow to show all available regions for current provider.

thinking there are 5 providers, first step - select provider, 2nd step-select region, 3rd set - select zone (or no zone), 4th - flavor and so on...

Same to other objects/resources.

Is your feature request related to a problem? Please describe.
Relating to #98

Describe the solution you'd like
Have terraform set your default connection information for server + baremetal. This will omit users having to define the their connection blocks like so:

   connection {
        type     = "ssh"
        host     = "ip"
        user     = "root"
        password = "password"
   }

Describe the bug
If a server is created from snapshot, subsequent refreshes read the os_id as the underlying OS in the snapshot, not the special meaning 164 (see #95 for more info), which means that a change is always detected:

      ~ os_id             = 244 -> 164
[...]
      snapshot_id       = "<checksum>"

where 244 is the underlying OS (Debian in this case) in the snapshot.

It's not good terraform practice to have spurious 'changes' like this, but it's worse in this case, since it actually prevents us from applying:

Error: Error occured while updating os_id for server <N> : Invalid operating system.

i.e. we cannot update in-place (and we certainly don't want to re-create every time!) to the special os_id = 164.

To Reproduce
Steps to reproduce the behavior:

1. Create a vultr_server resource with os_id = 164 and valid snapshot_id
2. terraform apply, wait for success
3. terraform plan, note the planned 'change'
4. terraform apply, note the failure

Expected behavior
terraform plan in reproduction step 3 should show no change.

Is your feature request related to a problem? Please describe.
I was installing Kubernetes using this, and met timeout. So I wanted to extend timeout but it doesn't work.

# first attempt - timeout
terraform apply
# ...
# vultr_server.master_standalone: Still creating... [5m40s elapsed]
# vultr_server.master_standalone: Still creating... [5m50s elapsed]
# vultr_server.master_standalone: Still creating... [6m0s elapsed]
# Error: timeout - last error: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain

# second attempt - timeout not supporting
terraform plan
# ...
# Error: Unsupported block type
#  on a.tf line 44, in resource "vultr_server" "master_standalone":
#  44:   timeouts {
# Blocks of type "timeouts" are not expected here.

# my template

resource "vultr_server" "master_standalone" {
	plan_id = "${data.vultr_plan.plan_2c4g.id}"
	region_id = "${data.vultr_region.tokyo.id}"
	os_id = "${data.vultr_os.coreos.id}"
	hostname = "master-01"
	provisioner "file" {
    source      = "common.sh"
    destination = "/tmp/common.sh"
  }
  provisioner "remote-exec" {
    inline = [
      "chmod +x /tmp/common.sh",
      "/tmp/common.sh",
    ]
  }
  timeouts {
    create = "10m"
  }
}

Describe the solution you'd like
timeout support
https://www.terraform.io/docs/configuration/resources.html#timeouts

Describe alternatives you've considered
I just got rid of "/tmp/common.sh" from my template.

Additional context
Thank you for official repository providing!

Describe the bug
I want to create a server and use the iPXE Custom Script option, as available in the UI (via Upload ISO -> iPXE Custom Script) which contains a iPXE script.

To Reproduce
Steps to reproduce the behavior:

1. Create a server

resource "vultr_server" "ipxe" {
  region_id            = "1"
  plan_id              = "202"
  script_id            = "${vultr_startup_script.pxe.id}"
}

resource "vultr_startup_script" "pxe" {
  name   = "pxe"
  type   = "pxe"
  script = "pxe script"
}

2. Run terraform apply

Expected behavior
Create the server using the iPXE custom script just as in the UI.

Desktop (please complete the following information where applicable:

• Version : v1.0.0

Additional context

If you leaved out any of the required reference IDs, you get the error:

Error: Please select at least one of the following os_id, app_id, iso_id or snapshot_id                                                                        

If you set the os_id to the Custom one (159), you end up with:

Error: Please set a corrosponding attribute                                    

If I comment out this error (https://github.com/vultr/terraform-provider-vultr/blob/master/vultr/resource_vultr_server.go#L274), it seems to work fine (I get the result I want)

Hey Team, 👋 My name is Chris, I'm a member of the Partner team @ HashiCorp.

I’ve taken a look at the provider here and would like to say great work so far! I do have feedback outlined below that I’d like to see addressed before we move on to the next steps. I’m opening this issues as a sort of checklist for tracking items and discussion. The review was done on the develop branch at git commit 01aecfc

• All the attributes should be read and set in READ so that differences between the configuration and the actual state can be caught. Any non-scalar values (TypeList, TypeSet, TypeMap) should have errors checked when setting. The first instance of this is the v6_networks attribute in the BearMetalServer resource. Check out this plan attribute in the Azure provider for reference. ](https://github.com/terraform-providers/terraform-provider-azurerm/blob/master/azurerm/resource_arm_virtual_machine.go#L743)

• All official Terraform provider use a Mozilla Public License 2.0](https://www.mozilla.org/en-US/MPL/2.0/) within each repo, can you add this LICENSE](https://github.com/terraform-providers/terraform-provider-azurerm/blob/master/LICENSE) file to this repository.

• There are three Makefile targets that should be added for the providers website documentation. website, website-lint, and website-test. They can be found in any of the provider GNUmakefile](https://github.com/terraform-providers/terraform-provider-azurerm)

• When running the Go acceptance testing there was just one test that continuously failing. Any thoughts on what might be causing it?

=== RUN   TestAccVultrBackup
--- FAIL: TestAccVultrBackup (1.17s)
    testing.go:568: Step 0 error: errors during refresh:

        Error: your search returned too many results : 2. Please refine your search to be more specific

          on /var/folders/bf/6n0whcjn2x17rp19q0yc2vfc0000gn/T/tf-test568318980/main.tf line 2:
          (source code not available)

Describe the bug
If you specify a snapshot_id only, you get an error on a vultr_server resource that os_id is required.

If you then add os_id = data.vultr_snapshot.mysnapshot.os_id, the apply succeeds but the resulting server was not created from the snapshot, it's just the same OS as the snapshot's os_id, as if the snapshot_id wasn't specified at all.

To Reproduce

resource "vultr_server" "test" {
  region_id         = "${data.vultr_region.test.id}"
  plan_id           = "${data.vultr_plan.test.id}"
  os_id             = "${data.vultr_snapshot.test.os_id}"  # error if not specified
  snapshot_id       = "${data.vultr_snapshot.test.id}"
  # ...
}

Expected behavior
os_id not required if snapshot_id is specified.

or at least, if it is required, snapshot_id is still used.

Desktop (please complete the following information where applicable:

Terraform v0.12.5
[...]
+ provider.vultr (unversioned)

Additional context

Add any other context about the problem here.

Describe the bug
It seems like one can't use script_id with os_id.

Aka setting the OS to say Ubuntu and at the same time requiring a startup script.

To Reproduce
Steps to reproduce the behavior:
Launch server with a os_id and script_id set.

Expected behavior
Use script with specific os chosen.