Bug 867513
Summary: | expose host subject also in VM properties (add <certificate> element and its contents to <vm><display> element as well) | ||
---|---|---|---|
Product: | Red Hat Enterprise Virtualization Manager | Reporter: | David Jaša <djasa> |
Component: | ovirt-engine-restapi | Assignee: | Michael Pasternak <mpastern> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | David Jaša <djasa> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | 3.1.0 | CC: | bazulay, cfergeau, dyasny, ecohen, iheim, mpastern, Rhev-m-bugs, sgrinber, ykaul |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | virt | ||
Fixed In Version: | si22 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2012-12-04 20:01:37 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 783087, 806925 |
Description
David Jaša
2012-10-17 16:03:45 UTC
i see no point in not showing <host> in <vm> in user-api, as it can be seen via certificate-subject, instead i'd like exposing certificate not in <display>, but in <host> <vm> ... <host id=XXX> <certificate> <organization>YYY</organization> <subject>O=YYY,CN=ZZZ</subject> </certificate> </host> ... </vm> thoughts? only reason i'd argue these are display and not 'host', is that tomorrow the display information may be different. i.e., vm.display may point to an html5 websocket proxy instead of directly to a host. so while the certificate is of the host, the importance of this information is that its the details of the display, which may not be of a host. make sense? (In reply to comment #4) > only reason i'd argue these are display and not 'host', is that tomorrow the > display information may be different. > i.e., vm.display may point to an html5 websocket proxy instead of directly > to a host. > so while the certificate is of the host, the importance of this information > is that its the details of the display, which may not be of a host. > make sense? absolutely. another one: since <certificate> runs query to fetch the subject, should we only display it when accessing single vm (i.e not displaying it when listing vms)? (In reply to comment #6) > another one: since <certificate> runs query to fetch the subject, > should we only display it when accessing single vm (i.e not displaying it > when listing vms)? this is more around optimization of traffic. if i write something to monitor VMs, i don't care about it. if i write a user portal, i care about it. so if i can change the detail level via a header, to get it for a list of VMs, doesn't have to be there by default. btw, in any case to access a VM i'd have to do a setvmticket, so there may be a correlation between the two in the future (we don't have anything to hint that way, but maybe display should be related to the setvmticket operation?) (In reply to comment #7) > (In reply to comment #6) > > another one: since <certificate> runs query to fetch the subject, > > should we only display it when accessing single vm (i.e not displaying it > > when listing vms)? > > this is more around optimization of traffic. and easy on backend when you fetch >= 100 vms at once. > if i write something to monitor VMs, i don't care about it. > if i write a user portal, i care about it. not sure, if you want connect to vm, you have to access vm context. > > so if i can change the detail level via a header, to get it for a list of > VMs, doesn't have to be there by default. does not supported infrastructure-wise yet (but planned), i just see that other properties [1] has been set only in single vm context, so i wonder if it's a bug or feature. [1] such as Ballooning for instance. > > btw, in any case to access a VM i'd have to do a setvmticket, so there may > be a correlation between the two in the future (we don't have anything to > hint that way, but maybe display should be related to the setvmticket > operation?) certificate will be shown only when accessing specific vm resource, future api versions will alow user specifying if he wants to get entier entity [1] at collection resource. [1] https://bugzilla.redhat.com/show_bug.cgi?id=868626 http://gerrit.ovirt.org/#/c/8692/ si24: OK $ curl --cacert ... -u user@domain:pw -H "Content-Type: application/xml" -H "filter: true" -X GET https://rhevm31.spice.lab.eng.brq.redhat.com/api/vms/vm_uuid ... <vm ...> ... <display> ... <certificate> <subject>O=spice.lab.eng.brq.redhat.com,CN=10.34.58.7</subject> </certificate> </display> ... </vm> (In reply to comment #9) > certificate will be shown only when accessing specific vm resource, If so, what's point in displaying of <address>, <port> and <secure_port> all the time? They're useless without the <certificate> element so IMO you could omit them for non-specific-vm-resource queries and save some cpu cycles... Pre-3.1 API didn't display host subject in host properties either so such change could be pretty safe IMO. The same could apply to other detailed dynamic runtime information. (In reply to comment #15) > (In reply to comment #9) > > certificate will be shown only when accessing specific vm resource, > > If so, what's point in displaying of <address>, <port> and <secure_port> all > the time? They're useless without the <certificate> element so IMO you could > omit them for non-specific-vm-resource queries and save some cpu cycles... > 1. backward compatibility 2. admin may be aware of <certificate> and don't need accessing <vm/> for that, this way he can execute several spice sessions just running over the <vms/> collection. (In reply to comment #16) > (In reply to comment #15) > > (In reply to comment #9) > > > certificate will be shown only when accessing specific vm resource, > > > > If so, what's point in displaying of <address>, <port> and <secure_port> all > > the time? They're useless without the <certificate> element so IMO you could > > omit them for non-specific-vm-resource queries and save some cpu cycles... > > > > 1. backward compatibility This does apply to non-filtered results only > 2. admin may be aware of <certificate> and don't need accessing > <vm/> for that, this way he can execute several spice sessions just running > over the <vms/> collection. and this also applies just to admin results only. The CPU-cycles-saving point would have biggest impact for non-filtered results, allowing it to have larger page size with the same backend effort, but this is precisely where both your points do apply... |