Bug 1001477

Summary: OtherResourceType element is missing in ovf file when importing VM without VNIC profile
Product: Red Hat Enterprise Virtualization Manager Reporter: GenadiC <gcheresh>
Component: ovirt-engineAssignee: Moti Asayag <masayag>
Status: CLOSED CURRENTRELEASE QA Contact: GenadiC <gcheresh>
Severity: unspecified Docs Contact:
Priority: high    
Version: 3.3.0CC: acathrow, iheim, lpeer, myakove, Rhev-m-bugs, yeylon
Target Milestone: ---Keywords: Reopened
Target Release: 3.3.0   
Hardware: x86_64   
OS: Linux   
Whiteboard: network
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-08-27 08:29:23 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Network RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description GenadiC 2013-08-27 06:50:23 UTC
Description of problem:
OtherResourceType element is missing in ovf file when importing VM without VNIC profile (imported from 3.2 engine)

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


How reproducible:
Always

Steps to Reproduce:
1. Create VM in 3.2 environment and export this VM
2. Import this VM to 3.3 environment
3. Check the ovf file

Actual results:
OtherResourceType is missing in the ovf file

Expected results:
OtherResourceType should exist but be empty

Additional info:
When creating ovf file with VNIC profile the OtherResourceType does exist

Comment 1 Moti Asayag 2013-08-27 08:29:23 UTC
Since the vnic profiles feature was introduced in ovirt-engine 3.3, the OtherResourceType which represents the vnic profile name in the OVF should appear only in VMs/Templates exported from ovirt-engine 3.3.

Therefore it is legit not having this field on exported vm from ovirt-engine 3.2.

Comment 2 Itamar Heim 2013-08-27 17:43:18 UTC
re-opening so these two use cases will be tested:
1. export from 3.3 engine in 3.0-3.2 cluster levels should not have this, and should successfull import in a 3.0-3.2 engine (matching to export cluster level of course)

2. import to 3.2 and 3.3 cluster levels in a 3.3 engine works for a VM exported from 3.1 and 3.2 engine/cluster

Comment 3 Moti Asayag 2013-08-27 19:11:12 UTC
(In reply to Itamar Heim from comment #2)
> re-opening so these two use cases will be tested:
> 1. export from 3.3 engine in 3.0-3.2 cluster levels should not have this,
> and should successfull import in a 3.0-3.2 engine (matching to export
> cluster level of course)

Why there is concern regarding the appearance of this field (OtherResourceType which represents the vnic profile name) in 3.0-3.2 cluster levels ? It shouldn't cause the failure in import to engine 3.2 and will make the import to engine 3.3 (to any cluster level) more accurate.

> 
> 2. import to 3.2 and 3.3 cluster levels in a 3.3 engine works for a VM
> exported from 3.1 and 3.2 engine/cluster

Comment 4 Itamar Heim 2013-08-28 17:17:59 UTC
(In reply to Moti Asayag from comment #3)
> Why there is concern regarding the appearance of this field
> (OtherResourceType which represents the vnic profile name) in 3.0-3.2
> cluster levels ? It shouldn't cause the failure in import to engine 3.2 and
> will make the import to engine 3.3 (to any cluster level) more accurate.

i see this as a considerable concept change, hence worth specific import/export testing (actually, a test case for testing import/export for backward/forward compatibility should happen in each version anyway, but that's a good scenario to make sure it is covered for.

Comment 5 GenadiC 2013-09-03 14:48:50 UTC
Scenarios of importing VM with VNIC profile from 3.2 DC/CLuster to 3.2 DC/CLuster and from 3.3 to 3.2 were tested as a part of TCMS in other test cases

Comment 6 Itamar Heim 2014-01-21 22:31:53 UTC
Closing - RHEV 3.3 Released

Comment 7 Itamar Heim 2014-01-21 22:31:55 UTC
Closing - RHEV 3.3 Released

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