-
Notifications
You must be signed in to change notification settings - Fork 62
Description
Currently, the nexus-internal API combines together versioned endpoints and debugging-only ones used by omdb, such as blueprint_view:
omicron/openapi/nexus-internal.json
Lines 475 to 508 in d196e0c
| "get": { | |
| "summary": "Fetches one blueprint", | |
| "operationId": "blueprint_view", | |
| "parameters": [ | |
| { | |
| "in": "path", | |
| "name": "blueprint_id", | |
| "description": "ID of the blueprint", | |
| "required": true, | |
| "schema": { | |
| "type": "string", | |
| "format": "uuid" | |
| } | |
| } | |
| ], | |
| "responses": { | |
| "200": { | |
| "description": "successful operation", | |
| "content": { | |
| "application/json": { | |
| "schema": { | |
| "$ref": "#/components/schemas/Blueprint" | |
| } | |
| } | |
| } | |
| }, | |
| "4XX": { | |
| "$ref": "#/components/responses/Error" | |
| }, | |
| "5XX": { | |
| "$ref": "#/components/responses/Error" | |
| } | |
| } | |
| }, |
When the nexus-internal API is moved to being server-side versioned, any changes to these debugging APIs are going to be flagged as breaking ones and be rejected by our OpenAPI tooling. That's because the OpenAPI tooling attempts to generate an OpenAPI document from source, and then compare compatibility with blessed versions (which at the moment is just an equality check on the whole schema). For types like Blueprint which change often, any change to them is going to be flagged as incompatible.
- What if the changes are append-only or otherwise wire-compatible? Our tooling is not currently smart enough to detect append-only changes so we would still fail. But even in a hypothetical world where we could detect wire-compatible changes, there is no reason to enforce any kind of compatibility rule on
Blueprints, since the only thing that fetches them is omdb that is always lockstep-versioned with Nexus.
There are a few different ways to address this, but the simplest and cleanest is probably to separate out debugging-only APIs into their own lockstep-versioned API trait/OpenAPI document. We could run the corresponding server on the same port (with some work in Dropshot to allow combinations of API traits), or a different one (which would probably be easier).