Bug 1054948
Summary: | Spice proxy information for VMs not available through the API | ||
---|---|---|---|
Product: | [Retired] oVirt | Reporter: | iordan <iiordanov> |
Component: | ovirt-engine-api | Assignee: | Martin Betak <mbetak> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | bugs <bugs> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 3.3 | CC: | cfergeau, gianluca.cecchi, gklein, iheim, juan.hernandez, michal.skrivanek, rbalakri, yeylon |
Target Milestone: | --- | ||
Target Release: | 3.5.1 | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | virt | ||
Fixed In Version: | ovirt-3.5.0_rc2 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-01-21 16:02:52 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | Virt | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
iordan
2014-01-17 19:39:00 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. Thank you for making this a high-priority item, Itamar! 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. 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 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 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 #3 is a good suggestion, should not be that hard to add. weshould expose the token for rwebsockets too 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? 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. oVirt 3.5.1 has been released. If problems still persist, please make note of it in this bug report. |