Bug 1054948 - Spice proxy information for VMs not available through the API
Summary: Spice proxy information for VMs not available through the API
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: oVirt
Classification: Retired
Component: ovirt-engine-api
Version: 3.3
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 3.5.1
Assignee: Martin Betak
QA Contact: bugs@ovirt.org
URL:
Whiteboard: virt
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-17 19:39 UTC by iordan
Modified: 2016-02-10 19:50 UTC (History)
8 users (show)

Fixed In Version: ovirt-3.5.0_rc2
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-01-21 16:02:52 UTC
oVirt Team: Virt


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
oVirt gerrit 31350 master MERGED restapi: Expose effective SPICE proxy in VM.display Never
oVirt gerrit 31907 ovirt-engine-3.5 MERGED restapi: Expose effective SPICE proxy in VM.display Never

Description iordan 2014-01-17 19:39:00 UTC
Description of problem:

In Opaque, I recently started setting the proxy property of SpiceSession from the console file, as is done in remote-viewer, in order to support installations where the nodes are not "visible" from the point of view of the client that use spice-proxy:

    http://www.ovirt.org/Features/Spice_Proxy

However, then I remembered that I have not seen the proxy property being available through the oVirt/RHEV API. I looked at the latest remote-viewer code, and I looked through the oVirt/RHEV API documentation, and indeed, I see no way to get proxy information other than through the console.vv file.

This means that both Opaque and remote-viewer cannot connect to VMs behind a proxy unless a console.vv file is used, which also means that since console.vv files are currently unobtainable through the User Portal on mobile devices, mobile devices effectively cannot at all connect to such VMs if the user is not an Administrator using the Admin Portal.

We would need to expose the proxy parameter through the API, probably in the VM display parameter in order to allow Opaque and remote-viewer to connect to such VMs without going through the web interface and using a console.vv file.


Version-Release number of selected component (if applicable):

oVirt 3.3 was tested and shows the issue, but it is probably present in all past and current versions too.


How reproducible:

100%

Steps to Reproduce:

1. Browsing through the API shows no information about spice-proxy.
2. Looking through the API documentation finds no information about it.

Actual results:

Information about spice proxy unavailable through the API. Information about the parameter not available in the API documentation.

Expected results:

The opposite to the actual results :).

Comment 1 Itamar Heim 2014-01-17 20:56:52 UTC
its actually not present in previous versions, since its a new feature in 3.3, which seems to have missed adding the api part for this.

Comment 2 iordan 2014-01-17 23:50:52 UTC
Thank you for making this a high-priority item, Itamar!

Comment 3 Juan Hernández 2014-01-18 13:26:52 UTC
Currently, in the backend, we have a global "SpiceProxyDefault" configuration parameter, but it isn't accessible via the API.

Also, recently we introduced the capability to override this at the cluster and VM pool levels. This is already supported in the API. For example, for a cluster:

  <cluster id="..." href="...">
    <name>Default</name>
    ...
    <display>
      <proxy>the_proxy_address</proxy>
    </display>
  </cluster>

You can take advantage of this for a workaround: assign a proxy to the cluster or VM pool level, and then, in the Opaque code, find the cluster or VM pool corresponding to the VM, and get the proxy address from there.

I know that this isn't ideal.

What I would suggest as a definitive solution is to populate the "cluster.display.proxy" even if it isn't overridden: taking the value from the global configuration parameter. We should probably do the same for VMs: populate the already existing "vm.display.proxy" element from the cluster or from the global configuration parameter. This is similar to what we do for permissions.

This logic to calculate the proxy address should be part of the backend, not of the API, so that the GUI benefits from it as well.

Comment 4 iordan 2014-01-18 18:03:24 UTC
Hi Juan,

Thanks for detailing a possible workaround. I'll wait to see if there is a use-case for it.

It would be great if you eventually populate vm.display.proxy.

Thanks!
iordan

Comment 5 Michal Skrivanek 2014-04-10 09:45:36 UTC
this may get revisited when UI will use REST as we may need to expose all system config values anyway. Then it makes more sense to just expose the VM property and do not "resolve" the address

Comment 6 iordan 2014-04-17 18:30:34 UTC
Hi Michal,

Does that mean that you will not be fixing this issue or you will still fix it but revisit it later on?

Thanks!
iordan

Comment 7 Michal Skrivanek 2014-08-08 09:42:49 UTC
comment #3 is a good suggestion, should not be that hard to add.
weshould expose the token for rwebsockets too

Comment 8 Gianluca Cecchi 2014-10-31 11:50:33 UTC
What was the change introduced so that the bug went into ON_QA?
Does this mean that in 3.5.0 the proxy parameter is now exposed through api?

Comment 9 Juan Hernández 2014-10-31 11:59:28 UTC
The change introduced is that the proxy settings are propagated from the global settomg or from the cluster to each VM, so if you request a VM you will get something like this:

  GET /api/vms/{vm_id}
  <vm id="...">
    <display>
      <type>spice</type>
      <monitors>1</monitors>
      <proxy>http://myproxy.exampl.com:8080</proxy>  <-- This is proxy address
      ...
    </display>
  </vm>

So you no longer need the workaround described in comment 3, you can just get the "proxy" element from the VM itself.

Comment 10 Sandro Bonazzola 2015-01-21 16:02:52 UTC
oVirt 3.5.1 has been released. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.