Bug 1194287
| Summary: | VM display type in REST API doesn't have 1:1 match with GUI | ||
|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Einav Cohen <ecohen> |
| Component: | Frontend.WebAdmin | Assignee: | Tomas Jelinek <tjelinek> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Petr Kubica <pkubica> |
| Severity: | low | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | --- | CC: | bugs, ecohen, gklein, juan.hernandez, lsurette, mgoldboi, michal.skrivanek, pstehlik, rbalakri, s.kieske, yeylon, ykaul |
| Target Milestone: | ovirt-3.6.0-rc | Flags: | ylavi:
ovirt-3.6.0?
ylavi: planning_ack+ rule-engine: devel_ack+ ylavi: testing_ack? |
| Target Release: | 3.6.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | virt | ||
| Fixed In Version: | 3.6.0-4_alpha3 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-01-13 15:45:26 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
Einav Cohen
2015-02-19 13:34:18 UTC
it behaves like this: - web admin's subtab's "graphics protocol" shows the list of devices statically set for VM (regardless of the state of the VM as currently runs). e.g. if in edit VM set to SPICE it will show SPICE (btw it reads it from VmDevices) - web admin's main tab's "display" shows the data as returned from VDSM (e.g. the content of VM Dynamic). So if using run once changed from SPICE to VNC this will show the VNC instead of SPICE - the REST's "display" shows the dynamic data if present (e.g. if the VM is running) and falls back to show the static data if not. So, I think that: - the REST shows it correctly (e.g. if the VM is running than shows what is there in fact and if not than what is configured) - maintab shows only the dynamic value (same as for example for memory usage) and shows "None" if not running) so I'd say it is correct - subtab shows the static value which is AFAIK also correct and in line with the rest of the UI The only problem I see is with the naming (once called Display once Graphics protocol which does not signify that it is the same but once from dynamic configuration and once from static). Franta have proposed the name "Graphics" to be used in the main tab instead of "Display" which is certainly better but I'm not sure about it. @Einav: would that be a sufficient fix for you? Or can you suggest a better name? the renaming will definitely take care of the confusion, however I am still uncomfortable with having different pieces of information in the API and in the UI. isn't the "graphics protocol" (static) data important for REST API users as well, even when the VM is running? moreover: If tomorrow we will move the GUI to work over the REST API, we will not have the relevant data to bind to the GUI - what will we do then? I am 'needinfo'ing Juan for his take on this issue, but IMO: If the "graphics protocol" (static) data is / may be important to have, even while the VM is running - it should be available in the REST API. If it is not important - it should not be available at all, i.e. it should be hidden in the GUI. Users of the RESTAPI will probably want to get the information about the graphics capabilities of a VM for two reasons:
1. To use it in order to actually connect to one of the graphics devices of the VM when it is running.
2. To check or modify the characteristics of the graphics devices that will be used by default the next time the VM is started.
I think that both are important.
We have this same situation with CDROMS, for example, and in that case we are using a "current" matrix parameter to differentiate these two situations:
# Get the CDROMs that the VM is currently using:
GET /api/vms/{vm:id}/cdroms;current
# Get the CDROMS that the VM will use by default next time it is started:
GET /api/vms/{vm:id}/cdroms
In both cases the representation of the entity is the same, the difference is the content. We can do the same for graphics devices, but only with the new representation of graphics devices to be introduced in 3.6, we can't change how "display" currently behaves.
I have to say that I think that there shouldn't be these two "current" and "persistent" states, as it makes things confusing for users of the API. It would be better to require users to edit the VM before running it, instead of having a "run once" functionality.
the 43077 adds the support for ;current=true/false for the graphics devices to the REST the 38004 does the rename in webadmin now it should be consistent and the REST should be complete. Closing old bugs. In case still happens, pls reopen. |