This patch adds a new console type, "spice-direct", which provides
the connection information required to talk the native SPICE protocol
directly to qemu on the hypervisor. This is intended to be fronted
by a proxy which will handle authentication separately.
A new microversion is introduced which adds the type "spice-direct"
to the existing "spice" protocol.
An example request:
POST /servers/<uuid>/remote-consoles
{
"remote_console": {
"protocol": "spice",
"type": "spice-direct"
}
}
An example response:
{
"remote_console": {
"protocol": "spice",
"type": "spice-direct",
"url": "http://localhost:13200/nova?token=XXX";
}
}
This token can then be used to lookup connection details for the
console using a request like this:
GET /os-console-auth-tokens/<consoletoken>
Which returns something like this:
{
"console": {
"instance_uuid": <uuid>,
"host": <hypervisor>,
"port": <a TCP port number>,
"tls_port": <another TCP port number>,
"internal_access_path": null
}
}
APIImpact
Change-Id: I1e701cbabc0e2c435685e31465159eec09e3b1a0
RDP console was only for HyperV driver so removing the
API. As API url stay same (because same used for other
console types API), RDP console API will return 400.
Cleaning up the related config options as well as moving its
API ref to obsolete seciton.
Keeping RPC method to avoid error when old controller is used
with new compute. It can be removed in next RPC version bump.
Change-Id: I8f5755009da4af0d12bda096d7a8e85fd41e1a8c
The RDP console was only available for HyperV driver, therefore its
connection information via API ``os-console-auth-tokens`` will now return
HTTP ``400 (BadRequest)`` error.
Starting from 2.31 microversion, this API return connection info
for all other console type.
Change-Id: I94e590eb4cbe3b2d8eff7fe881f7b98af8979be2
This legacy service is no longer used and was deprecated during the
Stein cycle [1]. It's time to say adios and remove them in their
entirety. This is pretty straightforward, with the sole exception of
schema for the 'remote-consoles' API, which has to continue supporting
requests for type 'xvpvnc' even if we can't fulfil those requests now.
[1] https://review.opendev.org/#/c/610076/
Part of blueprint remove-xvpvncproxy
Depends-On: https://review.opendev.org/695853
Change-Id: I2f7f2379d0cd54e4d0a91008ddb44858cfc5a4cf
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
This exposes the 'nova-console' service via a REST API, a service that
can only be used with XVP VNC consoles, which in turn require the
'nova-xvpvncproxy' service. We we would like to remove the
'nova-console' and 'nova-xvpvncproxy' services, so start here.
Part of blueprint remove-xvpvncproxy
Change-Id: I2ee3b8c44e5d85e9b3c811ed3c5e6cddc563054f
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
This patch includes all the verifications of remote consoles
part of blueprint api-ref-in-rst-pike
Co-Authored-By: Markus Zoeller <mzoeller@linux.vnet.ibm.com>
Change-Id: Ib169e4bd931b5a04f31cd0e7c43c161b49eafe5c
Michael Still