Consolidate the APIs for getting consoles

We have different public API for getting console access for each kind of console that is supported in Nova. The proposal is to consolidate all these APIs into one.

Problem description

The APIs for getting console access are tightly coupled with the name of the underlying protocol: os-getVNCConsole, os-getRDPConsole, etc. The result is that every time we want to add support for a new console, we need to introduce a new public API. A far better solution is to have only one API, get_console, which can be used for obtaining access to all types of consoles.

Use Cases

As a Nova developer I want to add support for a new console type and I don’t want to add more clutter to the public API.

Project Priority


Proposed change

The proposal is to introduce a single public API for getting console access and deprecate all of the current public APIs that we have. The implementation will inspect the request and will call the relevant get_XXX_console of the ComputeManager.


The alternative is to keep adding public APIs for each new console type which is not really desired.

Data model impact


REST API impact

The new API will be only in v2.1 and it will have the following definition:


POST /servers/<uuid>/consoles
    "protocol": ["vnc"|"rdp"|"serial"|"spice"],
    "type": ["novnc"|"xpvnc"|"rdp-html5"|"spice-html5"]

The ‘type’ parameter in the request is optional and should be used when the chosen protocol supports multiple connection types.


200 OK
    "url": string,
    "protocol": ["vnc"|"rdp"|"serial"|"spice"],
    "type": ["novnc"|"xpvnc"|"rdp-html5"|"spice-html5"]

Some of failure scenarios and their corresponding error code include: * wrong values for protocol/type in the request - “400 Bad Request” * the instance is not yet ready - “409 Conflict” * the virt driver doesn’t support this console type - “501 Not Implemented”

Security impact


Notifications impact


Other end user impact

There will be a new ‘console-get’ subcommand for the Nova CLI that will support all of the console types.

Performance Impact


Other deployer impact


Developer impact




Primary assignee:


Work Items

The blueprint can be implemented in a single patch which adds the new API.


API Microversions


A new test will be added to tempest which will exercise the new API.

Documentation Impact

The new API should be documented and we should encourage users to use this instead of the old APIs which will be deprecated.