Le jeu. 4 avr. 2024 à 11:37, Michael Still <mikal@stillhq.com> a écrit :

Hi all,

for the longest time I've thought it was super cool that you could do something like this with Google Cloud:

`gcloud compute ssh ...instance...`

This causes a SSH session to run in your terminal that transparently proxies you through to the instance. It even orchestrates SSH authentication using a CA, but that's a story for another day.

Aptira had a similar business need, but with more of a focus on virtual desktop environments, and therefore kindly supported my development work on a SPICE protocol native proxy I've called Kerbside [1][2]. The proxy works by scraping various clouds' REST APIs for "VDI capable" instances, and then making those available via short lived session tokens. The intention is that a service like Horizon or Skyline could request a session token for a specific instance, which is returned to the user as a `.vv` style virt-viewer configuration file. The user then opens the configuration file and a connection to the console on the relevant hypervisor is provided by Kerbside.

Kerbside can do more than that of course. It has a simple management UI and API, which allows for things like forced termination of a console session once setup, logging and audit history, TLS support, and so forth. Kerbside and all associated work is licensed under the Apache 2 license, just the same as OpenStack, and positions clouds to offer Citrix-like virtual desktops to their users in a seamless manner.

Why a SPICE proxy? As best as I can tell, SPICE still provides the richest virtual desktop experience. It supports high resolution desktops, multi-screen desktops, USB device passthrough, sound, multiple user connections to a single console, and so forth.

Why not the current HTML5 transcoding proxy as used by Horizon? Unfortunately, the current HTML5 SPICE client does not support most of the features listed in the previous paragraph.

While originally intended for the purposes of my personal Shaken Fist project, Kerbside now supports OpenStack and oVirt as well. In the case of OpenStack, this required a number of patches to OpenStack projects to get working [3]. Specifically I'd like to propose a new Nova API microversion to support a new "spice-direct" console type. I intend to work through the Nova specs process for the Nova related changes, and have created a blueprint [4] to track that work. I am working on a draft spec at the moment [5], but do not see the required changes to Nova as particularly invasive. You can of course assess that yourself by reading the proof of concept patches in the kerbside-patches repository.

This raises some questions for me. Specifically:

- is this functionality interesting to others? Or is it just me?

- what is the process of proposing changes like this for Kolla and Kolla-Ansible? I chose to build my proof of concept on that platform, so I also have a number of aligned deployment patches there.

- I've been out of the OpenStack universe for a while now. Is it too late to propose this work for Dalmation?

From a procedural perspective (if I may say :-)), you're right on time for the Dalmatian release cycle, which just started. Feel free to upload your nova-specs patch into the dalmatian directory and then we'll be looking at it like other ones :-) -Sylvain Thanks,

Michael

1: https://github.com/shakenfist/kerbside and https://github.com/shakenfist/kerbside-client 2: Why Kerbside? Well because Horizon and Skyline are distant things, whereas I wanted to create something closer... Like Kerbside pickup from a shop. 3: https://github.com/shakenfist/kerbside-patches 4: https://blueprints.launchpad.net/nova/+spec/libvirt-spice-direct-consoles 5: https://github.com/shakenfist/kerbside-patches/blob/develop/nova-specs/patch...