Bug 1295852 - [RFE] Let the user change the name of an imported file Storage Domain
Summary: [RFE] Let the user change the name of an imported file Storage Domain
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: General
Version: 3.6.2
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ovirt-3.6.2
: 3.6.2.6
Assignee: Maor
QA Contact: Elad
URL:
Whiteboard:
: 1222571 (view as bug list)
Depends On:
Blocks: 1222571
TreeView+ depends on / blocked
 
Reported: 2016-01-05 15:44 UTC by Aharon Canan
Modified: 2016-02-23 13:59 UTC (History)
8 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2016-02-18 11:21:18 UTC
oVirt Team: Storage
Embargoed:
rule-engine: ovirt-3.6.z+
rule-engine: exception+
ylavi: planning_ack+
rule-engine: devel_ack+
acanan: testing_ack+


Attachments (Terms of Use)
Logs01 (805.76 KB, application/x-gzip)
2016-01-05 15:51 UTC, Aharon Canan
no flags Details


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 51439 0 master MERGED webadmin: Add storage attributes on import SD. 2016-01-06 16:26:15 UTC
oVirt gerrit 51455 0 ovirt-engine-3.6 ABANDONED webadmin: Add storage attributes on import SD. 2016-01-07 09:45:59 UTC
oVirt gerrit 51459 0 master MERGED core: Importing a SD should override empty fields 2016-01-06 17:12:32 UTC
oVirt gerrit 51464 0 ovirt-engine-3.6 MERGED core: Importing a SD should override empty fields 2016-01-07 13:21:09 UTC
oVirt gerrit 51474 0 master MERGED webadmin: Set properties only for File SD. 2016-01-07 09:40:45 UTC
oVirt gerrit 51479 0 ovirt-engine-3.6 MERGED webadmin: Add storage attributes on import SD. 2016-01-07 13:20:47 UTC
oVirt gerrit 51511 0 ovirt-engine-3.6.2 MERGED webadmin: Add storage attributes on import SD. 2016-01-08 07:51:31 UTC
oVirt gerrit 51512 0 ovirt-engine-3.6.2 MERGED core: Importing a SD should override empty fields 2016-01-08 07:50:44 UTC

Description Aharon Canan 2016-01-05 15:44:30 UTC
Description of problem:


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Aharon Canan 2016-01-05 15:50:37 UTC
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:

Comment 2 Aharon Canan 2016-01-05 15:51:29 UTC
Created attachment 1111900 [details]
Logs01

Comment 3 Tal Nisan 2016-01-06 10:34:37 UTC
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)

Comment 4 Maor 2016-01-06 15:45:04 UTC
Looks like this was never supported, 
This RFE should provide a proper fix for that :
https://bugzilla.redhat.com/1222571

Comment 5 Yaniv Lavi 2016-01-07 08:10:15 UTC
*** Bug 1222571 has been marked as a duplicate of this bug. ***

Comment 6 Aharon Canan 2016-01-07 08:16:03 UTC
if it was never supported then we should block this option or make it work.

Comment 7 Tal Nisan 2016-01-07 09:36:00 UTC
If it was never supported then it's an RFE and should be pushed out, can you confirm Maor?

Comment 8 Tal Nisan 2016-01-07 09:36:25 UTC
And obviously be blocked so it won't appear as if we are allowing it

Comment 9 Maor 2016-01-07 09:47:45 UTC
The name for NFS was never supported, but I'm not sure about the name textbox

Comment 10 Tal Nisan 2016-01-07 09:58:36 UTC
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

Comment 11 Aharon Canan 2016-01-18 14:28:16 UTC
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"

Comment 12 Red Hat Bugzilla Rules Engine 2016-01-18 14:28:19 UTC
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.

Comment 13 Maor 2016-01-19 12:52:10 UTC
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

Comment 14 Red Hat Bugzilla Rules Engine 2016-01-20 11:51:10 UTC
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.

Comment 15 Sandro Bonazzola 2016-01-20 14:03:21 UTC
(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

Comment 16 Maor 2016-01-20 16:53:33 UTC
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

Comment 17 Elad 2016-02-02 17:00:25 UTC
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

Comment 18 Red Hat Bugzilla Rules Engine 2016-02-02 17:00:27 UTC
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.

Comment 19 Maor 2016-02-02 19:14:00 UTC
(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"

Comment 20 Maor 2016-02-02 19:44:39 UTC
Changed the doc text to be more clear

Comment 21 Red Hat Bugzilla Rules Engine 2016-02-03 09:18:27 UTC
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.

Comment 22 Elad 2016-02-08 09:26:04 UTC
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

Comment 23 Maor 2016-02-23 13:59:42 UTC
Removing the verified=failedQA since the problem was only related to the doc text phrasing and not the fix it self.


Note You need to log in before you can comment on or make changes to this bug.