Bug 913607

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Daniel, can you give more details on how the info host/port and cookie will be given to the client? Can we assume it rely on .vv connection file parameters?

Should remote-viewer/spice-gtk support ws:// uri ? How would it differentiate between spice or vnc then? Apparently, there is a subprotocol field for that, and we should consider registering: http://www.iana.org/assignments/websocket/websocket.xml. That would need some negociation in this case.

Is this somehow testable today with openstack? Or can it just be implemented against a websockify spice server?

thanks

For the way OpenStack has implemented the proxy you need to connect to a URL

   http(s)://hostname:port/websockify

and have set a cookie called 'token' containing the authentication token openstack provided. The 'token' values are time limits, single use only auth keys.

Now what actual URI we define for use with spice-gtk / remote-viewer is rather up to us to define, since the OpenStack API doesn't define this. For a generic websocket proxied remote viewer, we could say something like this is required:

 spice+ws://hostname:port/websockify?token=foobar

For an OpenStack specific URI though,  we could use an spice+openstack://  URI scheme and pass in the hostname of the openstack authentication server (keystone) along with the UUID of the virtual instance. Then auto-lookup the hostname/port + token of the virtual instance display, as we do with oVirt.

(In reply to Daniel Berrange from comment #4)
> For the way OpenStack has implemented the proxy you need to connect to a URL
> 
>    http(s)://hostname:port/websockify
> 
> and have set a cookie called 'token' containing the authentication token
> openstack provided. The 'token' values are time limits, single use only auth
> keys.

Ok, is this already implemented in openstack? It will redirect websocket connection from this address to the server? Is it documented somewhere?

> Now what actual URI we define for use with spice-gtk / remote-viewer is
> rather up to us to define, since the OpenStack API doesn't define this. For
> a generic websocket proxied remote viewer, we could say something like this
> is required:
> 
>  spice+ws://hostname:port/websockify?token=foobar
> 
> For an OpenStack specific URI though,  we could use an spice+openstack:// 
> URI scheme and pass in the hostname of the openstack authentication server
> (keystone) along with the UUID of the virtual instance. Then auto-lookup the
> hostname/port + token of the virtual instance display, as we do with oVirt.

I am not that familiar with openstack (keystone), or oVirt. So I don't get that part. I suppose "token" here is the same as the token in cookie in openstack example above, but the auth server will require login/pass.

I am afraid this bug can't be implemented simply with a websockify spice server, since it requires some cookie handling. So it would be nice to have some help how to setup openstack (or use an instance we can try against)

(In reply to Marc-Andre Lureau from comment #5)
> (In reply to Daniel Berrange from comment #4)
> > For the way OpenStack has implemented the proxy you need to connect to a URL
> > 
> >    http(s)://hostname:port/websockify
> > 
> > and have set a cookie called 'token' containing the authentication token
> > openstack provided. The 'token' values are time limits, single use only auth
> > keys.
> 
> Ok, is this already implemented in openstack? It will redirect websocket
> connection from this address to the server? Is it documented somewhere?

Yep, latest openstack includes this SPICE websock proxy support. It doesn't redirect the client, rather you're going via a tunnelled proxy. So the single public facing websockets display server, can be used to access VMs across any host in the cloud. Thus the individual virtualization hosts are not public facing.

> 
> > Now what actual URI we define for use with spice-gtk / remote-viewer is
> > rather up to us to define, since the OpenStack API doesn't define this. For
> > a generic websocket proxied remote viewer, we could say something like this
> > is required:
> > 
> >  spice+ws://hostname:port/websockify?token=foobar
> > 
> > For an OpenStack specific URI though,  we could use an spice+openstack:// 
> > URI scheme and pass in the hostname of the openstack authentication server
> > (keystone) along with the UUID of the virtual instance. Then auto-lookup the
> > hostname/port + token of the virtual instance display, as we do with oVirt.
> 
> I am not that familiar with openstack (keystone), or oVirt. So I don't get
> that part. I suppose "token" here is the same as the token in cookie in
> openstack example above, but the auth server will require login/pass.

Keystone is the name of OpenStack's authentication server. The user will typically have access to that server by setting env variables with their authentication credentials. With such authenticated access to keystone you can then access the compute service, where you can find out the address of the display server and ask for a one-time token to connect to a specify guest.

> I am afraid this bug can't be implemented simply with a websockify spice
> server, since it requires some cookie handling. So it would be nice to have
> some help how to setup openstack (or use an instance we can try against)

Ping me out of band and I can help you setup a suitable openstack instance, or failing that I can give you access to one of mine.

I started a blueprint to use HTTP proxy instead. The patch are in gerrit (spice-http-proxy)

https://blueprints.launchpad.net/nova/+spec/spice-http-proxy

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

It appears that the spice-http-proxy code has been abandoned. Has there been any further definition or documentation of the websockets approach? What's the proper way, for example to wrap the spice-gtk client? It wants a standard spice uri which ends up choking on the token when passed.

(In reply to josh from comment #10)
> It appears that the spice-http-proxy code has been abandoned. Has there been
> any further definition or documentation of the websockets approach? What's
> the proper way, for example to wrap the spice-gtk client? It wants a
> standard spice uri which ends up choking on the token when passed.

It is not abandoned, in the sense that I still think it's a better approach than implementing websockets: https://blueprints.launchpad.net/nova/+spec/spice-http-proxy. all the patches were ready to be merged for a while.

I think implementing websocket in the native client is the wrong approach.

Daniel, do you still think this is a desirable solution or should we close this bug now? thanks

If we do the plain https tunnelling of SPICE in openstack, then client support for the websockets tunnelling would not be a critical feature any more.

Tbh, I still think this doesn't make sense for Spice & spice-gtk.

Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.