Skip to content

Move nexus-internal debugging APIs to a separate lockstep-versioned interface and OpenAPI document #8902

@sunshowers

Description

@sunshowers

Currently, the nexus-internal API combines together versioned endpoints and debugging-only ones used by omdb, such as blueprint_view:

"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).

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions