Ability to specify a linked silo in IP Pool resource

[askfongjojo]

Overview

The recent enhancement in v0.4.0 allows user to create the IP pool but the pool isn't usable until it has been linked to a silo. We'll need the ability to do so at the time an IP Pool resource is created.

Implementation details

No response

Anything else you would like to add?

Non-requirements: ability to make pool-silo linkage changes afterwards, need for linking to multiple silos (one is good enough, if that can simplify things).

[karencfv]

Thanks for opening up this issue @askfongjojo! I can see how it would be annoying to use the oxide_ip_pool resource without a resource to link said IP pools.

I have a draft PR that "should" be working but it appears I may have hit a bug in the API. When I apply the following terraform HCL file I have no trouble creating the resource.

provider "oxide" {}

resource "oxide_ip_pool" "test" {
  description       = "a test ip_pool"
  name              = "terraform-acc-myippool"
  ranges = [
    {
    first_address = "172.20.15.227"
    last_address  = "172.20.15.230"
     }
  ]
}

resource "oxide_ip_pool_silo_link" "test" {
  silo_id = "1fec2c21-cf22-40d8-9ebd-e5b57ebec80f"
  ip_pool_id = oxide_ip_pool.test.id
  is_default = true
}

But when I run terraform plan it tells me there are no IP pool-silo links (?!?!)

$ terraform plan
oxide_ip_pool.test: Refreshing state... [id=081a331d-5ee4-4a23-ac8b-328af5e15cdc]
oxide_ip_pool_silo_link.test: Refreshing state... [id=68da789a-417f-4542-9a89-82d5f986cedd]

Planning failed. Terraform encountered an error while generating this plan.

╷
│ Error: Missing resource
│ 
│   with oxide_ip_pool_silo_link.test,
│   on z.tf line 25, in resource "oxide_ip_pool_silo_link" "test":
│   25: resource "oxide_ip_pool_silo_link" "test" {
│ 
│ Unable to find requested link between IP pool 081a331d-5ee4-4a23-ac8b-328af5e15cdc and silo 1fec2c21-cf22-40d8-9ebd-e5b57ebec80f
╵

At first I assumed this was a bug in my code, that I was somehow not actually creating the link, but after some debugging I was able to see the GET /v1/system/ip-pools/{pool}/silos doesn't appear to be working.

When I try to recreate a link between an IP pool and a silo via the CLI it tells me this link already exists:

$ oxide api -X post /v1/system/ip-pools/081a331d-5ee4-4a23-ac8b-328af5e15cdc/silos --field silo=1fec2c21-cf22-40d8-9ebd-e5b57ebec80f --field is_default=false
error; status code: 400 Bad Request
{
  "error_code": "ObjectAlreadyExists",
  "message": "already exists: ip-pool-resource \"ip_pool_id: 081a331d-5ee4-4a23-ac8b-328af5e15cdc, resource_id: 1fec2c21-cf22-40d8-9ebd-e5b57ebec80f, resource_type: Silo\"",
  "request_id": "e4bf793b-52a1-458b-bf85-56ec65f1b8e4"
}
error

But when I try to list the links, nothing appears!

$ oxide api -X get /v1/system/ip-pools/081a331d-5ee4-4a23-ac8b-328af5e15cdc/silos 
{
  "items": [],
  "next_page": null
}

Now, I'm only able to test this via my local simulated set-up. I think it's unlikely that the list links API endpoint doesn't work. I don't really have access to test these system endpoints on a rack. Do you have access? Would it be possible for you to try out the list links endpoint on a real rack to see if this is a simulated environment issue? If it's not, I'd be happy to open up an issue on the omicron repo to fix this endpoint.

Sadly, this resource cannot work without a read endpoint, so I'll mark this as blocked until the issue is resolved :)

[askfongjojo]

Hrm, the API is still working (I just verified it quickly through the console on Dogfood). This is the POST request payload:

Request URL:
https://oxide.sys.rack2.eng.oxide.computer/v1/system/ip-pools/another-pool/silos
Request Method:
POST
Status Code:
201 Created
Remote Address:
172.20.26.3:443

{
    "ip_pool_id": "4a29d2f9-8169-4009-84c7-0c8e35759e47",
    "silo_id": "faef7d63-2aa1-4921-b913-96a2b82814e8",
    "is_default": false
}

Afterwards, I got back one additional silo (there were two originally before my POST request)

https://oxide.sys.rack2.eng.oxide.computer/v1/system/ip-pools/another-pool/silos?limit=25
{
    "next_page": "eyJ2IjoidjEiLCJwYWdlX3N0YXJ0Ijp7InNvcnRfYnkiOiJpZF9hc2NlbmRpbmciLCJsYXN0X3NlZW4iOiJmYWVmN2Q2My0yYWExLTQ5MjEtYjkxMy05NmEyYjgyODE0ZTgifX0=",
    "items": [
        {
            "ip_pool_id": "4a29d2f9-8169-4009-84c7-0c8e35759e47",
            "silo_id": "047ae077-63aa-48c8-8908-68a00a34e167",
            "is_default": true
        },
        {
            "ip_pool_id": "4a29d2f9-8169-4009-84c7-0c8e35759e47",
            "silo_id": "c7dd16b8-255e-4300-8e52-7396a72caf3e",
            "is_default": false
        },
        {
            "ip_pool_id": "4a29d2f9-8169-4009-84c7-0c8e35759e47",
            "silo_id": "faef7d63-2aa1-4921-b913-96a2b82814e8",
            "is_default": false
        }
    ]
}

[karencfv]

Hmmm... Ok, so this is probably an issue with the simulated environment then. I'll wrap up this PR and find a way to test it against a real environment. I probably wouldn't test it on dogfood though, these tests are pretty destructive 😄 I'll ask Augustus for a test silo or something. Thanks!

[karencfv]

Ha! I found the culprit. The test-silo in the simulated omicron is not discoverable. Apparently that means when I try to list the links to IP pools, all I get is an empty response. TIL