Bug 1195724

Looks as though we just need to apply the mapper on the domain passed to the POST call, no?

(In reply to Allon Mureinik from comment #1)
> Looks as though we just need to apply the mapper on the domain passed to the
> POST call, no?

no, this is an issue also related to the GUI and it is the behavior we have today for export Storage Domain.
We don't have this feature for re-define name, description and more.
Currently we can't import an Export Domain which have the same name as another Storage domain in the setup.

to fix this behavior we should think how do we want to show this in the dialog box when importing a Storage Domain.
for example, we can have a checkbox which will be checked only if the user does not want to use the defaults configured in the Storage Domain, and then one can redefine all the rest of the fields.

I've opened an RFE on that which this bug will be dependent on since we should fix that issue in the REST and in the GUI as well for Export and Data Storage Domains

After verifying import for NFS it appears that from REST we do support redefine of name, description and comment (see [1]), although keep in mind that the new definitions will not be updated in the Storage Domain metadata unless the user will change one of those fields when the Storage Domain will be active.
Is this still relevant?



[1]
<storage_domain>
    <name>new_name</name>
    <description>new_description</description>
    <comment>new_comment</comment>
    <type>data</type>
    <storage>
        <address>10.35.16.2</address>
        <type>nfs</type>
        <path>/export/images/rnd/maor/data3</path>
    </storage>
    <host>
        <name>venus-vdsa.tlv.redhat.com</name>
    </host>
    <storage_format>v3</storage_format>
</storage_domain>

(In reply to Maor from comment #3)
> After verifying import for NFS it appears that from REST we do support
> redefine of name, description and comment (see [1]), although keep in mind
> that the new definitions will not be updated in the Storage Domain metadata
> unless the user will change one of those fields when the Storage Domain will
> be active.
> Is this still relevant?
> 
> 
> 
> [1]
> <storage_domain>
>     <name>new_name</name>
>     <description>new_description</description>
>     <comment>new_comment</comment>
>     <type>data</type>
>     <storage>
>         <address>10.35.16.2</address>
>         <type>nfs</type>
>         <path>/export/images/rnd/maor/data3</path>
>     </storage>
>     <host>
>         <name>venus-vdsa.tlv.redhat.com</name>
>     </host>
>     <storage_format>v3</storage_format>
> </storage_domain>

My mistake, for NFS there is no support curently, will send a fix for that issue

Maor, is there anything that should be documented here?

(In reply to Allon Mureinik from comment #5)
> Maor, is there anything that should be documented here?

I'm not sure, it is only potential fields which we already use when adding a new Storage Domain, and the rsdl.wsdl is already synced with them

An example to import NFS Storage Domain:

<storage_domain>
    <description>NewDescription</description>
    <comment>anyComment</comment>
    <type>data</type>
    <storage>
        <address>10.35.16.2</address>
        <type>nfs</type>
        <path>/export/images/rnd/maor/data3</path>
    </storage>
    <host>
        <name>venus-vdsa.tlv.redhat.com</name>
    </host>
    <storage_format>v3</storage_format>
    <wipe_after_delete>true</wipe_after_delete>
</storage_domain>

An example to import SCSI Storage Domain:

<storage_domain id="43aab646-776f-4ae7-bc01-87a7c9880c73">
  <name>scsi1</name>
  <comment>newComment</comment>
  <description>MyNewDescription</description>
  <wipe_after_delete>true</wipe_after_delete>
  <import>true</import>
  <host id="b78f820b-6653-4405-b466-ee15032e0cda" />
  <type>data</type>
  <storage>
     <type>iscsi</type>
  </storage>
</storage_domain>

Maor, isn't the fix should include the webadmin fields?
right now, I confirm that this bug is verified only over rest-api

(In reply to Ori Gofen from comment #8)
> Maor, isn't the fix should include the webadmin fields?
> right now, I confirm that this bug is verified only over rest-api

There is another RFE which handles this
see https://bugzilla.redhat.com/show_bug.cgi?id=1195784

Verified using vt15 on rest-api, based on comment #9 the UI issue will be handled at bz #1195784

This is an automated message.
oVirt 3.5.3 has been released on June 15th 2015 and should include the fix for this BZ. Moving to closed current release.