Context:
The OpenAPI for ocm-api-model is generated from the ocm-api-metamodel generator, which currently does not emit operationId values on operations. Many code generators and tools rely on operationId to produce stable, well-named client methods.
Request:
Add first-class support in the metamodel generator to include a deterministic operationId (or, alternatively, a vendor extension such as x-sdk-operation-name) for each operation in the generated OpenAPI.
Why:
- Improves DX for SDK/codegen users (OpenAPI Generator, Swagger Codegen, etc.)
- Enables stable client method names across releases
- Facilitates better IDE navigation and API discoverability
Backlinks:
Non-goals (for scoping):
- No hand-editing of the generated OpenAPI in ocm-api-model.
- No changes to the API surface itself; this is metadata emitted by the generator.
Acceptance considerations:
- operationId (or vendor extension) is emitted for all operations in generated specs.
- Values are unique and deterministic across runs/releases.
- Minimal/no breaking impact on existing downstreams (opt-in flag is fine if necessary).
- Basic docs in the generator repo explaining the naming strategy and how to enable/disable it.
Context:
The OpenAPI for ocm-api-model is generated from the ocm-api-metamodel generator, which currently does not emit operationId values on operations. Many code generators and tools rely on operationId to produce stable, well-named client methods.
Request:
Add first-class support in the metamodel generator to include a deterministic operationId (or, alternatively, a vendor extension such as x-sdk-operation-name) for each operation in the generated OpenAPI.
Why:
Backlinks:
Non-goals (for scoping):
Acceptance considerations: