Description of problem:
I tried to set new name while importing ISO gluster domain, once the domain created, I got the old domain name instead of the new one I set.

Version-Release number of selected component (if applicable):
vdsm-4.17.15-0.el7ev.noarch
rhevm-3.6.2-0.1.el6.noarch

How reproducible:
100%

Steps to Reproduce:
1. click import domain
2. set "name" different from the domain name
3. 

Actual results:
we got the old name instead of the new name I set

Expected results:
New name should appear

Additional info:

Created attachment 1111900 [details]
Logs01

Not a critical bug but a paper cut, Maor, see if we can get this converged to 3.6.2 (in case it's a simple fix)

Looks like this was never supported, 
This RFE should provide a proper fix for that :
https://bugzilla.redhat.com/1222571

*** Bug 1222571 has been marked as a duplicate of this bug. ***

if it was never supported then we should block this option or make it work.

If it was never supported then it's an RFE and should be pushed out, can you confirm Maor?

And obviously be blocked so it won't appear as if we are allowing it

The name for NFS was never supported, but I'm not sure about the name textbox

OK, so restore the original RFE you closed as dup and use this bug to block the editing in the UI, makes no sense to have a box that looks editable when it's not really editable

rhevm-3.6.2.5-0.1.el6.noarch
vdsm-4.17.17-0.el7ev.noarch

Steps to Reproduce:
===================
1. Import Data/ISO/Export domains, do not set name and click "OK"
2. Import Data/ISO/Export domains, set different name and click "OK" + activate it


Actual results:
===============
1. SD gets the old name from the metadata
2. SD gets the new name you set and not the old one from the metadata but after activating it, the metadata wasn't updated as well although it should according to the "Doc text"

Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.

I don't know why this bug was switched to ON_QA for rhevm-3.6.2.5-0.1.el6.noarch.
This fix is only supported for rhevm-3.6.2.7-0.1.el6.noarch and above.

Moving back to Modified please remove the failedQA

Bug tickets that are moved to testing must have target release set to make sure tester knows what to test. Please set the correct target release before moving to ON_QA.

(In reply to Maor from comment #13)
> I don't know why this bug was switched to ON_QA for
> rhevm-3.6.2.5-0.1.el6.noarch.
> This fix is only supported for rhevm-3.6.2.7-0.1.el6.noarch and above.
> 

There won't be a 3.6.2.7 I think, if it missed 3.6.2.6 will be 3.6.3
If it's included in 3.6.2.6 please set target release and move to QE otherwise we'll pick this up in 3.6.3.


> Moving back to Modified please remove the failedQA

I don't see any tag for rhev-3.6.2-6.
I only see that this patch was merged before rhev-3.6.2-7, ..2-8, ..2-9, ..2-10
I think that means that it should be targeted to 3.6.3

Maor,

I'm getting the same results as in comment #11
After importing an existing ISO / export domain and changing its name, the name that appears in the DB is the updated one while in the SD's metadata and also in getStorageDomainInfo, the old name exists.


# select id,storage_name from storage_domains;


                  id                  | storage_name 
--------------------------------------+--------------
 ebe6e231-4313-4614-9cb4-107e16e3f059 | export1





[root@green-vdsa dom_md]# vdsClient -s 0 getStorageDomainInfo ebe6e231-4313-4614-9cb4-107e16e3f059
        uuid = ebe6e231-4313-4614-9cb4-107e16e3f059
        version = 0
        role = Regular
        remotePath = 10.35.64.11:/vol/RHEV/Storage/elad/3
        type = NFS
        class = Backup
        pool = ['738bbdf7-7961-4507-ad7a-3314666634b0']
        name = export


[root@green-vdsa dom_md]# cat metadata 
CLASS=Backup
DESCRIPTION=export
IOOPTIMEOUTSEC=10
LEASERETRIES=3
LEASETIMESEC=60
LOCKPOLICY=
LOCKRENEWALINTERVALSEC=5
POOL_UUID=738bbdf7-7961-4507-ad7a-3314666634b0
REMOTE_PATH=10.35.64.11:/vol/RHEV/Storage/elad/3
ROLE=Regular
SDUUID=ebe6e231-4313-4614-9cb4-107e16e3f059
TYPE=NFS
VERSION=0
_SHA_CKSUM=30893017b67225a8a4bc6760ff3604da0882ada3


I'm using:
rhevm-3.6.3-0.1.el6.noarch
vdsm-4.17.19-0.el7ev.noarch

Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.

(In reply to Elad from comment #17)
> Maor,
> 
> I'm getting the same results as in comment #11
> After importing an existing ISO / export domain and changing its name, the
> name that appears in the DB is the updated one while in the SD's metadata
> and also in getStorageDomainInfo, the old name exists.

That is basically what the fix suppose to do.

> Steps to Reproduce:
> ===================
> 1. Import Data/ISO/Export domains, do not set name and click "OK"
> 2. Import Data/ISO/Export domains, set different name and click "OK" + activate it
> 
> 
> Actual results:
> ===============
> 1. SD gets the old name from the metadata 
      - That is what it basically suppose to do.
 "if the name field will be blank then the value from the Storage Domain metadata will be initialized" - meaning that the Storage Domain's name in the DB will be initialized with the name from the metadata.
If that is not clear from the comment, I can rephrase it.

> 2. SD gets the new name you set and not the old one from the metadata but 
> after activating it, the metadata wasn't updated as well although it should \
> according to the "Doc text"
     - Doc text indicates that the Metadata should be changed once the Storage Domain will be updated meaning editing it while it is active.
  "...until the user will update the Storage Domain once it is active"

Changed the doc text to be more clear

Bug tickets that are moved to testing must have target release set to make sure tester knows what to test. Please set the correct target release before moving to ON_QA.

From doc text:

"For the user to change the Storage Domain's name description in the metadata, one will need to update the Storage Domain while it is active and change the storage domain's name to a different name, press ok, and back again, update the Storage Domain and change the Storage Domain's name to the one he or she desires."

This is the current behaviour as described in comment #17 with the additional part of the way to change the domain name in the metadata (editing it and changing the name when the it's active).

Therefore, moving to VERIFIED. 

Tested with:
rhevm-3.6.3-0.1.el6.noarch
vdsm-4.17.19-0.el7ev.noarch

Removing the verified=failedQA since the problem was only related to the doc text phrasing and not the fix it self.