Add address lot resource and data source.

[jmcarp]

Resolves #468.
Resolves #469.

[jmcarp]

Manual acceptance testing, for now:

❯ TEST_ACC_NAME=TestAccAddressLot make testacc          
-> Running terraform acceptance tests
=== RUN   TestAccAddressLot
=== PAUSE TestAccAddressLot
=== CONT  TestAccAddressLot
--- PASS: TestAccAddressLot (1.91s)
PASS
ok  	github.com/oxidecomputer/terraform-provider-oxide/internal/provider	2.258s

❯ TEST_ACC_NAME=TestAccDataSourceAddressLot make testacc
-> Running terraform acceptance tests
=== RUN   TestAccDataSourceAddressLot
=== PAUSE TestAccDataSourceAddressLot
=== CONT  TestAccDataSourceAddressLot
--- PASS: TestAccDataSourceAddressLot (0.92s)
PASS
ok  	github.com/oxidecomputer/terraform-provider-oxide/internal/provider	1.270s

[internet-diglett]

Looks like this resolves #306 as well

[sudomateo]

Nice work on this! I left some feedback to update documentation and to confirm that the nested id attribute within the blocks attribute is okay because we've seen issues with non-empty refresh plans in the past with such a setup. I've discussed this issue on other pull requests (#426 (comment)) if you're curious for context.

[sudomateo]

Let's note that this can be infra or pool.

[jmcarp]

Done.

[sudomateo]

I've run into issues with nested computed attributes within sets before. The acceptance tests generally enforce that there's an empty refresh plan after applying a resource but the acceptance tests only use one block. Can you update the acceptance tests to use multiple blocks and see if there's any issue?

Alternatively, could you apply this resource with multiple blocks, dump the state file, run terraform refresh, and dump the state file again? I just want to ensure we're not shipping changes that'll result in non-empty refresh plans.

[jmcarp]

Applied the following resource:

resource "oxide_address_lot" "test" {
        description       = "a test address lot"
        name              = "terraform-acc-my-address-lot"
        kind              = "infra"
        blocks = [
                {
                        first_address = "172.0.1.1"
                        last_address  = "172.0.1.10"
                },
                {
                        first_address = "172.0.2.1"
                        last_address  = "172.0.2.10"
                },
        ]
}

Dump state: terraform state show oxide_address_lot.test > state-after-apply.

Refresh: terraform refresh.

Dump state again:terraform state show oxide_address_lot.test > state-after-refresh.

Get an empty diff with diff state-after-apply state-after-refresh.

This behavior, plus the passing acceptance test with multiple blocks, makes me think we're ok in this case.

[sudomateo]

Some of our APIs don't have an update method but instead use the create method as both create and update. Can you quickly test whether a "patch" to the create endpoint is explicitly disallowed before we move forward with an error diag here?

[jmcarp]

joshcarp@j0sh ~/c/omicron (jmcarp/prereqs-omit-sudo)> oxide api -X PATCH /v1/system/networking/address-lot
error; status code: 405 Method Not Allowed
{
  "message": "Method Not Allowed",
  "request_id": "014253b3-a094-4af5-aeb6-cc76055ebe71"
}

[sudomateo]

Hm, you do already have multiple blocks in the test. I wonder if truly the nested computed attribute in sets is only an issue when it's nested deeper than the top level. The testing I asked for in another comment would show more.

[sudomateo]

Just noting that this will also need a changelog entry.