Bug 950129

see also  https://bugzilla.redhat.com/show_bug.cgi?id=949546#c8

dup of bug 675830?

Daniel, don't we already support this query in the API?

(What I'm about to write is about VMs but applies to templates as well):

The feature requested in this bugzilla is to enable ordering, by disk space consumption, of VMs on a data domain. 

But in the API we do not support displaying VMs on data domains in the first place. The reason for this is, that a VM's disks may be scattered across several data domains, and thus a VM does not 'belong' to any single data domain. The only case where a VM can be thought of as contained in a storage-domain, is in the case export domains. 

Thus, the API command: 

  GET .../api/storagedomains/xxx/vms

is meant only for export domains. If 'xxx', above, is the ID of a data domain - no VMs are returned. 

What we *do* show in the context of a data domain, is disks. Here an order-by would be possible. We could add a URI-header, which, if supplied, means that the user would like the disks of this domain to be returned ordered by data consumption.

I think that the user can achieve the same result combining the already existing "max" matrix parameter and the "search" query parameter, like this:

  https://rhel.example.com/api/disks;max=10?search=storage=Data%20sortby%20actual_size%20desc

Is this enough? If so I would suggest to close the bug as NOTABUG.

(In reply to Juan Hernández from comment #9)
> I think that the user can achieve the same result combining the already
> existing "max" matrix parameter and the "search" query parameter, like this:
> 
>  
> https://rhel.example.com/api/disks;
> max=10?search=storage=Data%20sortby%20actual_size%20desc
> 
> Is this enough? If so I would suggest to close the bug as NOTABUG.

Daniel?

(In reply to Ayal Baron from comment #10)
> (In reply to Juan Hernández from comment #9)
> > I think that the user can achieve the same result combining the already
> > existing "max" matrix parameter and the "search" query parameter, like this:
> > 
> >  
> > https://rhel.example.com/api/disks;
> > max=10?search=storage=Data%20sortby%20actual_size%20desc
> > 
> > Is this enough? If so I would suggest to close the bug as NOTABUG.
> 
> Daniel?

IIUC, the functionality requested by this RFE should resembles VMs sub-tab under Storage main-tab in the webadmin. The sub-tab displays VMs with disks located on the selected storage domain. For overcoming performance issues, the sub-tab displayed only top 10 VMs with largest disks - this limitation has been removed in 3.3. Question is whether we're interested to retrieve VMs or disks from the rest-api. If we only need the disks then the solution suggested by Juan is indeed enough. Otherwise, we need to find a means to get also the VMs from the api.

(In reply to Daniel Erez from comment #11)
> (In reply to Ayal Baron from comment #10)
> > (In reply to Juan Hernández from comment #9)
> > > I think that the user can achieve the same result combining the already
> > > existing "max" matrix parameter and the "search" query parameter, like this:
> > > 
> > >  
> > > https://rhel.example.com/api/disks;
> > > max=10?search=storage=Data%20sortby%20actual_size%20desc
> > > 
> > > Is this enough? If so I would suggest to close the bug as NOTABUG.
> > 
> > Daniel?
> 
> IIUC, the functionality requested by this RFE should resembles VMs sub-tab
> under Storage main-tab in the webadmin. The sub-tab displays VMs with disks
> located on the selected storage domain. For overcoming performance issues,
> the sub-tab displayed only top 10 VMs with largest disks - this limitation
> has been removed in 3.3. Question is whether we're interested to retrieve
> VMs or disks from the rest-api. If we only need the disks then the solution
> suggested by Juan is indeed enough. Otherwise, we need to find a means to
> get also the VMs from the api.

You can programmatically get to the VMs from the disks, no?
Ravi also posted a patch for fetching the *disks*, does that ease the user experience?

(In reply to Ayal Baron from comment #12)
> (In reply to Daniel Erez from comment #11)
> > (In reply to Ayal Baron from comment #10)
> > > (In reply to Juan Hernández from comment #9)
> > > > I think that the user can achieve the same result combining the already
> > > > existing "max" matrix parameter and the "search" query parameter, like this:
> > > > 
> > > >  
> > > > https://rhel.example.com/api/disks;
> > > > max=10?search=storage=Data%20sortby%20actual_size%20desc
> > > > 
> > > > Is this enough? If so I would suggest to close the bug as NOTABUG.
> > > 
> > > Daniel?
> > 
> > IIUC, the functionality requested by this RFE should resembles VMs sub-tab
> > under Storage main-tab in the webadmin. The sub-tab displays VMs with disks
> > located on the selected storage domain. For overcoming performance issues,
> > the sub-tab displayed only top 10 VMs with largest disks - this limitation
> > has been removed in 3.3. Question is whether we're interested to retrieve
> > VMs or disks from the rest-api. If we only need the disks then the solution
> > suggested by Juan is indeed enough. Otherwise, we need to find a means to
> > get also the VMs from the api.
> 
> You can programmatically get to the VMs from the disks, no?

It would be simpler to use GetVmsByStorageDomainQuery as the UI does. The issue is representing it in the API (see comment #8).

> Ravi also posted a patch for fetching the *disks*, does that ease the user
> experience?

It can already be achieved using a search query as Juan suggested in comment #9.

(In reply to Daniel Erez from comment #13)
> (In reply to Ayal Baron from comment #12)
> > (In reply to Daniel Erez from comment #11)
> > > (In reply to Ayal Baron from comment #10)
> > > > (In reply to Juan Hernández from comment #9)
> > > > > I think that the user can achieve the same result combining the already
> > > > > existing "max" matrix parameter and the "search" query parameter, like this:
> > > > > 
> > > > >  
> > > > > https://rhel.example.com/api/disks;
> > > > > max=10?search=storage=Data%20sortby%20actual_size%20desc
> > > > > 
> > > > > Is this enough? If so I would suggest to close the bug as NOTABUG.
> > > > 
> > > > Daniel?
> > > 
> > > IIUC, the functionality requested by this RFE should resembles VMs sub-tab
> > > under Storage main-tab in the webadmin. The sub-tab displays VMs with disks
> > > located on the selected storage domain. For overcoming performance issues,
> > > the sub-tab displayed only top 10 VMs with largest disks - this limitation
> > > has been removed in 3.3. Question is whether we're interested to retrieve
> > > VMs or disks from the rest-api. If we only need the disks then the solution
> > > suggested by Juan is indeed enough. Otherwise, we need to find a means to
> > > get also the VMs from the api.
> > 
> > You can programmatically get to the VMs from the disks, no?
> 
> It would be simpler to use GetVmsByStorageDomainQuery as the UI does. The
> issue is representing it in the API (see comment #8).

So let's keep this open to allow for that.

> 
> > Ravi also posted a patch for fetching the *disks*, does that ease the user
> > experience?
> 
> It can already be achieved using a search query as Juan suggested in comment
> #9.

According to the comments above, this doesn't seem as though it's really required.

If it is, please provide a clear explanation why and reopen.