[BUG] - vultr_instance_ipv4.reboot does not seem to serve intended purpose

[5ampl3]

Describe the bug From what I can tell vultr_instance_ipv4.reboot argument does not satisfy whatever back end processes are needed within Vultr to utilize the additional ipv4 address on the resulting instance/ipv4 resource pair. That or documentation does not provide enough background/example to utilize properly.

To Reproduce

terraform {
  required_providers {
    vultr = {
      source  = "vultr/vultr"
    #   version = "2.11.4"
    }
  }
}

provider "vultr" {
  rate_limit  = 700
  retry_limit = 3
}

resource "vultr_instance" "instance_1" {
  plan             = "vc2-1c-1gb"
  region           = "atl"
  os_id            = 1743
  label            = "instance-1"
  tags             = ["instance-1"]
  hostname         = "instance-1"
  enable_ipv6      = false
  backups          = "disabled"
  ddos_protection  = false
  activation_email = false
}

resource "vultr_instance_ipv4" "instance_1_extra_ipv4" {
  instance_id = "${vultr_instance.instance_1.id}"
  reboot      = true
}

Expected behavior I would not expect to have to either manually hit the Vultr API to restart the instance or use the Vultr console to restart the VM to be able to use the additional IP address with the reboot argument either set or defaulting to true.

I have had Ansible setup the proper network configuration after the instance comes up but even with an Ansible triggered reboot I can not utilize this secondary IP address until hitting the Vultr API or web console to restart the instance.

[optik-aper]

I think the issue here is that the reboot flag is meant to only be passed on creation so it's not something that we want to track in TF state. We also don't want to assume that when someone creates a new IP resource that we can safely reboot the machine. I'll investigate what the options are here because I agree with you in principle that this should be something that we can manage from the TF provider.

[optik-aper]

I just realized I was looking at the wrong resource so, half of what I said about tracking the state is not accurate. But I'm investigating nonetheless.