Bug 1522799

Summary:	[RFE] - DR: On template\vm registration, vnic_profile_mappings should be under registration_configuration
Product:	[oVirt] ovirt-engine	Reporter:	eraviv
Component:	Backend.Core	Assignee:	eraviv
Status:	CLOSED CURRENTRELEASE	QA Contact:	Michael Burman <mburman>
Severity:	low	Docs Contact:
Priority:	medium
Version:	future	CC:	bugs, danken, lveyde, mburman, mlipchuk, myakove, ylavi
Target Milestone:	ovirt-4.2.1	Keywords:	FutureFeature
Target Release:	---	Flags:	rule-engine: ovirt-4.2? ylavi: exception+ rule-engine: planning_ack? rule-engine: devel_ack+ rule-engine: testing_ack+
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:	ovirt-engine-4.2.1.3	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-02-12 11:54:13 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:
Embargoed:
Bug Depends On:	1524149, 1530814
Bug Blocks:

Description eraviv 2017-12-06 13:29:24 UTC

Description of problem: 

Currently when registering a template or a vm, the REST API model accepts <vnic_profile_mappings> as a stand-alone entity in the action body of the REST request. 

But the <vnic_profile_mappings> should appear under the <registration_configuration> entity which has been added in 4.2.0


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


How reproducible:
100%

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Maor 2018-01-02 16:21:04 UTC

As part of this fix we should also include the change of using network name and profile name without the use of profile_id, since the id attribute is an internal property which the user should not be aware of it.
So the mapping should be as follow:
- primary_network_name: ovirtmgmt
  primary_profile_name: ovirtmgmt
  secondary_network_name: ovirtmgmt2
  secondary_profile_name: ovirtmgmt2

Comment 2 eraviv 2018-01-21 12:06:53 UTC

Causes a regression in ost 007_sd_reattach.import_lost_vm: reassign bad macs flag is ignored when VM is registered via REST.
moved back to post to provide fix

Comment 3 eraviv 2018-01-25 10:24:11 UTC

example of a request when the vm being registered has a MAC on one of its vnics  which is out of range:

http://{{user}}:{{pass}}@{{host}}:{{port}}/ovirt-engine/api/storagedomains/{{sd-id}}/vms/{{vm-id}}/register

<action>
    <cluster id="{{cluster-id}}"/>
    <reassign_bad_macs>true</reassign_bad_macs>
    <registration_configuration>
	    <vnic_profile_mappings>
        	<registration_vnic_profile_mapping>
	        	<from>
	        		<name>{{name}}</name>
	        		<network>
	        			<name>{{name}}</name>
	        		</network>
	        	</from>
	            <to id="{{vnic-profile-id}}"/>
        	</registration_vnic_profile_mapping>
	    </vnic_profile_mappings>
    </registration_configuration>
</action>

the request failed before the fix and should pass after it.

Comment 4 eraviv 2018-01-25 10:34:33 UTC

(In reply to Maor from comment #1)
> As part of this fix we should also include the change of using network name
> and profile name without the use of profile_id, since the id attribute is an
> internal property which the user should not be aware of it.
> So the mapping should be as follow:
> - primary_network_name: ovirtmgmt
>   primary_profile_name: ovirtmgmt
>   secondary_network_name: ovirtmgmt2
>   secondary_profile_name: ovirtmgmt2

Will be implemented under BZ-1530814

Comment 5 Michael Burman 2018-01-28 15:06:27 UTC

Verified on - 4.2.1.3-0.1.el7

Comment 6 Sandro Bonazzola 2018-02-12 11:54:13 UTC

This bugzilla is included in oVirt 4.2.1 release, published on Feb 12th 2018.

Since the problem described in this bug report should be
resolved in oVirt 4.2.1 release, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.