Bug 1295742

While looking at dumps of the XML REST API communication between
remote-viewer and the RHEV instance, I've noticed this:

> GET /ovirt-engine/api/storagedomains HTTP/1.1

< <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
< <storage_domains>
<     <storage_domain href="/ovirt-engine/api/storagedomains/b85e609a-c9dc-4d14-bfd9-03b6c2c93fba" id="b85e609a-c9dc-4d14-bfd9-03b6c2c93fba">
<         <name>iso</name>
<         <type>iso</type>
<     </storage_domain>
<     <storage_domain href="/ovirt-engine/api/storagedomains/b85e609a-c9dc-4d14-bfd9-03b6c2c93fba" id="b85e609a-c9dc-4d14-bfd9-03b6c2c93fba">
<         <name>iso</name>
<         <type>iso</type>
<     </storage_domain>

There are 2 ISO domains with the same UUID, which do not seem
right.

I'm told that this RHEV setup has 2 different DCs, each one with the same ISO storage domain attached to it.

Excerpt from an email thread about this with Juan Hernandez and Eli Mesika:
«
> I believe that this is a bug, as the RESTAPI shouldn't list twice the
> same object, with the same identifier. You may workaround it making
> sure that each ISO domain is attached to only one data center. That is
> kind of limiting, but it is the only solution that I can offer at the
> moment.
>
> The root cause of this is that the RESTAPI calls the
> "GetAllStorageDomains" query, that calls the
> "getallfromstorage_domains" stored procedure. This stored procedure
> does a "select * from storage_domains". The "storage_domains" view is
> constructed joining the storage domain tables and the
> "storage_pool_iso_map" table, using a left outer join. Thus if an ISO
> domain is attached N times then the result will contain it N times,
> two in this particular case.
>
> Eli, any suggestion on what is the best way to address this issue?

Since currently we have no limitation on attaching the same ISO to multiple DCs (and I think we shouldn't limit that), I think that this is a bug that can be resolved by adding a DISTINCT directive to the query which will maybe make the code less efficient (since this requires an implicit sorting based on all columns by the database), but , in this case , because this query is called from API on demand , I think that its impact on performance is minor

So, I suggest opening a BZ on that and assign it to me , we will decide if to address it only to 4.0 or also to 3.6.z
»