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-restapiAssignee: Michael Pasternak <mpastern>
Status: CLOSED CURRENTRELEASE QA Contact: David Jaša <djasa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 3.1.0CC: 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
Description of problem:
expose host subject also in VM properties (add <certificate> element and its contents to <vm><display> element as well)

Bug 807384 adds certificate info to /api/hosts/<host_uuid> which is unavailable when "filter: true" header (mimicking UP behaviour) is set - therefore even with bug 807384 implemented, it isn't possible to connect to the console as a regular user. Asking for blocker because of this issue.

In addition, if this isn't implemented, admins need one more REST API query to get all the console information just to get the host subject.

Version-Release number of selected component (if applicable):
si19.1 / rhevm-restapi-3.1.0-18.el6ev.noarch

How reproducible:
always

Steps to Reproduce:
1. as a user with some VM and no admin role, run:
curl -k -u {RHEVM_USER}:${PASS} -H "filter: true" \
    -H "Content-Type: application/xml" -X GET \
    https://your-rhevm.example.com.com/api/vms/${VM_UUID}
2.
3.
  
Actual results:
no host info nor subject info is displayed

Expected results:
subject info should be displayed:
<vms>
    <vm>
        ...
        <display>
            <!-- the same format as in <host><certificate> in
                    /api/hosts/${HOST_UUID} -->
            <certificate>
                <organization>${ORG}</organization>
                <subject>O=${ORG},CN=${HOST_NAME_OR_IP}</subject>
            </certificate>
            ...
        </display>
    </vm>
</vms>

Additional info:

Comment 3 Michael Pasternak 2012-10-21 08:28:17 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?

Comment 4 Itamar Heim 2012-10-21 08:40:43 UTC
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?

Comment 5 Michael Pasternak 2012-10-21 08:56:51 UTC
(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.

Comment 6 Michael Pasternak 2012-10-21 09:35:13 UTC
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)?

Comment 7 Itamar Heim 2012-10-21 09:55:53 UTC
(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?)

Comment 8 Michael Pasternak 2012-10-21 10:05:56 UTC
(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?)

Comment 9 Michael Pasternak 2012-10-21 11:00:50 UTC
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/

Comment 12 David Jaša 2012-11-06 14:24:10 UTC
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>

Comment 15 David Jaša 2012-11-07 14:11:30 UTC
(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.

Comment 16 Michael Pasternak 2012-11-08 07:04:32 UTC
(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.

Comment 17 David Jaša 2012-11-08 10:06:51 UTC
(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...