oxide_instance: attribute to read external IP addresses

[sudomateo]

Currently the oxide_instance resource has an external_ips attribute that users use to specify whether they want ephemeral or floating external IPs for the instance. However, the upstream instance_create API does not return those IP addresses back to the caller, forcing us to make a separate API call to instance_external_ip_list. This asymmetry in the schema means that we can't just overwrite the external_ips attribute for the user since that'll conflict with what they specified in the configuration.

This issue is to consider updating the oxide_instance resource to return all the external IPs for the instance so that users don't have to use the oxide_instance_external_ips data source and potentially turn that data source into an apply-time data source (e.g., instance just created so data source is deferred to apply).

[sudomateo]

Today, users wishing to use a provisioner with oxide_instance would have to do something like this, which is kinda a bad user experience.

data "oxide_instance_external_ips" "example" {
  instance_id = oxide_instance.example.id
}

resource "oxide_instance" "example" {
  project_id  = data.oxide_project.example.id
  description = "testing"
  name             = "testing"
  host_name        = "testing"
  memory           = 8589934592
  ncpus            = 2
  disk_attachments = [oxide_disk.example.id]

}

resource "terraform_data" "example" {
  triggers_replace = oxide_instance.example.id

  provisioner "remote-exec" {
    connection {
      type        = "ssh"
      user        = "ubuntu"
      private_key = file("./id_ed25519")
      // Be sure to filter out SNAT IPs here.
      host        = data.oxide_instance_external_ips.example.external_ips[0].ip
    }

    inline = ["ls /tmp"]
  }
}

If users tried to use the provisioner directly within oxide_instance, they would run into a cycle like so.

╷
│ Error: Cycle: data.oxide_instance_external_ips.example, oxide_instance.example
│
│
╵

[sudomateo]

I'm working on updating the Oxide Cloud Controller Manager with a service controller in oxidecomputer/oxide-cloud-controller-manager#106. Since Oxide doesn't have a load balancer today, this controller would work by allocating and attaching floating IPs to an instance. However, this would be incompatible with Terraform since it'll attempt to remove the floating IP.

  # oxide_instance.talos["talos-03"] will be updated in-place
  ~ resource "oxide_instance" "talos" {
      ~ external_ips       = [
          - {
              - id   = "6e33354c-6549-4d35-b95a-7f3a6a4121ef" -> null
              - type = "floating" -> null
            },
            # (1 unchanged element hidden)
        ]
        id                 = "280555a4-cc4e-4197-ace9-d0c4abb1931d"
        name               = "talos-03"
      ~ time_created       = "2025-11-19 02:07:14.215753 +0000 UTC" -> (known after apply)
      ~ time_modified      = "2025-11-19 02:07:14.215753 +0000 UTC" -> (known after apply)
        # (9 unchanged attributes hidden)
    }

If we had separate external_ips and attached_external_ips attributes this update wouldn't occur and instead the attached_external_ips attribute would refresh during the next plan or refresh operation.