Bump API for versioning and disk types

[david-crespo]

New way of fetching the API schema for client gen

With oxidecomputer/omicron#9430, the external API is now versioned. In #2981 we bumped the client generator to pass the version header. In this change we update the client generation script because instead of pointing at omicron/openapi/nexus.json, there is now a symlink at omicron/openapi/nexus/nexus-latest.json that tells us which file the actual spec is in. I don't know if there's some way to get GitHub to follow the symlink for you, but it's simple enough to fetch the symlink to get the target file and then fetch the target file.

Problems that are no longer problems

• Disks get a disk_type field that has one possible value — crucible — but in Local storage 2/4: Add the new disk type omicron#9409 that is going to change to distributed/local, so maybe we don't want to bother putting it in as crucible yet. This is now in here as distributed/local
• There are a bunch of endpoints added around multicast groups. Those are fine, but we're getting a type error in the generated Zod validators used by the mock server to validate request bodies. Most likely this is a generator bug, but sometimes it means the types in the schema are suboptimal. I need to look into that. Fixed in Handle nullable arrays in zod validators oxide.ts#317 and brought in in fe507b4

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Review	Updated (UTC)
console	Ready	Preview	Dec 30, 2025 8:43pm

[david-crespo]

Updated this for the latest commit on oxidecomputer/omicron#9543, which isn't merged yet. sledId is going to be removed — we are fine here because we're not using it. Future field naming changes will be trivial to integrate.

[david-crespo]

I put it back to the latest omicron main instead of that unmerged PR so we can merge this already and make further changes separately. I added disk type to the table on instance create, which works fine IMO:

Except we have a width problem with long disk names:

Prior to this change we deal with this by eliding the long name with an ellipse, though even then we seem to have made our truncate length a little too long:

With the extra column there, I have to go all the way down to truncating at 16 to get it to look right. I'm honestly not sure whether this is tolerable or not. Certainly it would be unwieldy to work with a few disks whose names have a long common prefix.