Bug 950023

Summary: webadmin: edit of master domain will show domain format as v2 when domain is in v1 format
Product: Red Hat Enterprise Virtualization Manager Reporter: Dafna Ron <dron>
Component: ovirt-engine-webadmin-portalAssignee: Federico Simoncelli <fsimonce>
Status: CLOSED CURRENTRELEASE QA Contact: yeylon <yeylon>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 3.2.0CC: abaron, acanan, acathrow, amureini, ecohen, iheim, jkt, Rhev-m-bugs, scohen, srevivo, yeylon
Target Milestone: ---Keywords: Triaged
Target Release: 3.3.0Flags: scohen: Triaged+
Hardware: x86_64   
OS: Linux   
Whiteboard: storage
Fixed In Version: is18 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-01-21 22:14:09 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Storage RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
screen shot and logs none

Description Dafna Ron 2013-04-09 13:26:41 UTC
Created attachment 733222 [details]
screen shot and logs

Description of problem:

I wanted to extend my master domain which is in 3.0 DC and with V1 domains.
the edit domain dialogue lists the domain as V2 format when the domain is V1.
this is only for the master domain (other domains under the same pool appear as v1).
and all the domains are v1 (in vds) and when I extended the format is still v1 (so UI issue).

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

sf13 with vdsm-4.10.2-1.9.el6ev.x86_64

How reproducible:

100%

Steps to Reproduce:
1. create a 3.0 DC, hosts with vdsm-4.10.2-1.9.el6ev.x86_64
2. create v1 format domain and attach it to the DC
3. edit the domain
 
Actual results:

UI is reporting false format for master domains created as V1 when we edit the domain

Expected results:

UI should be reporting correct version.

Additional info: screen shot and logs from extend



root@cougar01 ~]# vdsClient -s 0 getStorageDomainInfo bba99ec7-fedf-4002-bf4e-fae0f0eb035f
	uuid = bba99ec7-fedf-4002-bf4e-fae0f0eb035f
	vguuid = W74Mus-emTh-EeeX-qQuU-CRaz-Med7-EHAzUQ
	lver = 0
	state = OK
	version = 0
	role = Master
	pool = ['d6c49b67-d719-499a-9f4a-0c00ac22ba63']
	spm_id = 1
	type = ISCSI
	class = Data
	master_ver = 1
	name = Dafna-31-01


[root@cougar01 ~]# vgs -o vg_all /dev/bba99ec7-fedf-4002-bf4e-fae0f0eb035f
  Fmt  VG UUID                                VG                                   Attr   VSize   VFree   SYS ID Ext     #Ext Free MaxLV MaxPV #PV #LV #SN Seq VG Tags             #VMda #VMdaUse VMdaFree  VMdaSize  #VMdaCps 
  lvm2 W74Mus-emTh-EeeX-qQuU-CRaz-Med7-EHAzUQ bba99ec7-fedf-4002-bf4e-fae0f0eb035f wz--n- 199.25g 144.38g        128.00m 1594 1155     0     0   2   8   0  21 RHAT_storage_domain     4        2    64.00m   128.00m unmanaged

Comment 2 Federico Simoncelli 2013-09-16 14:40:22 UTC
To be able to test the fix for this bug, you also need:

http://gerrit.ovirt.org/#/c/19193
(Not related to the fix but it will let you have a DC V3.0 with domains V1).

Comment 3 vvyazmin@redhat.com 2013-10-13 11:50:11 UTC
Tested on iSCSI Data Centers
Verified, tested on RHEVM 3.3 - IS18 environment:

Host OS: RHEL 6.5

RHEVM:  rhevm-3.3.0-0.25.beta1.el6ev.noarch
PythonSDK:  rhevm-sdk-python-3.3.0.15-1.el6ev.noarch
VDSM:  vdsm-4.13.0-0.2.beta1.el6ev.x86_64
LIBVIRT:  libvirt-0.10.2-27.el6.x86_64
QEMU & KVM:  qemu-kvm-rhev-0.12.1.2-2.412.el6.x86_64
SANLOCK:  sanlock-2.8-1.el6.x86_64

Comment 7 Itamar Heim 2014-01-21 22:14:09 UTC
Closing - RHEV 3.3 Released

Comment 8 Itamar Heim 2014-01-21 22:21:57 UTC
Closing - RHEV 3.3 Released