Bug 1522799 - [RFE] - DR: On template\vm registration, vnic_profile_mappings should be under registration_configuration
Summary: [RFE] - DR: On template\vm registration, vnic_profile_mappings should be unde...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: Backend.Core
Version: future
Hardware: All
OS: All
medium
low
Target Milestone: ovirt-4.2.1
: ---
Assignee: eraviv
QA Contact: Michael Burman
URL:
Whiteboard:
Depends On: 1524149 1530814
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-12-06 13:29 UTC by eraviv
Modified: 2018-02-12 11:54 UTC (History)
7 users (show)

Fixed In Version: ovirt-engine-4.2.1.3
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-02-12 11:54:13 UTC
oVirt Team: Network
Embargoed:
rule-engine: ovirt-4.2?
ylavi: exception+
rule-engine: planning_ack?
rule-engine: devel_ack+
rule-engine: testing_ack+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 85088 0 master MERGED api-model: move vnic profiles mappings inside registration configuration 2017-12-14 11:03:46 UTC
oVirt gerrit 85222 0 master MERGED common: move vnic profiles mappings inside registration configuration 2018-01-11 08:43:46 UTC
oVirt gerrit 85223 0 master MERGED core: move vnic profiles mappings inside registration configuration 2018-01-11 08:43:51 UTC
oVirt gerrit 85224 0 master MERGED restapi: move vnic profiles mappings inside registration configuration 2018-01-15 11:52:34 UTC
oVirt gerrit 85428 0 model_4.2 MERGED api-model: move vnic profiles mappings inside registration configuration 2017-12-20 10:12:27 UTC
oVirt gerrit 85622 0 master MERGED restapi: Update to model 4.2.27 2017-12-20 12:45:52 UTC
oVirt gerrit 86518 0 master MERGED Updating the model version to 4.2.28 2018-01-18 07:57:15 UTC
oVirt gerrit 86613 0 master MERGED restapi: move vnic profiles mappings inside registration configuration - fix 2018-01-21 17:57:29 UTC

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.


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