Bug 1047887

similar failure occurs with Java SDK

There are 2 signatures for the add/update vm nic via the api, via url:
- name: /vms/{vm:id}/nics/{nic:id}|rel=update

signatures:
      - mandatoryArguments: {}
        optionalArguments: {nic.vnic_profile.id: 'xs:string', nic.linked: 'xs:boolean', nic.name: 'xs:string', nic.mac.address: 'xs:string', nic.interface: 'xs:string', nic.plugged: 'xs:boolean'}
        description: update the network interface for the given virtual machine
      - mandatoryArguments: {}
        optionalArguments: {nic.network.id|name: 'xs:string', nic.linked: 'xs:boolean', nic.name: 'xs:string', nic.mac.address: 'xs:string', nic.interface: 'xs:string', nic.port_mirroring.networks.network--COLLECTION: {network.id: 'xs:string'}, nic.plugged: 'xs:boolean'}

Where the first signature expects the vnic profile id only, and the second supports the network name for backward compatibility.

On 4.0 we should clear the deprecated signature and support vnic actions only with the profile id.

In order to work with the vnic profile, here are 2 samples both for python-sdk 
and for java-sdk where the network name should be nullified:

example of ovirt-engine-sdk-python:
vm1 = api.vms.get('vm1')
nic = vm1.nics.get('nic1')
nic.vnic_profile = api.vnicprofiles.get('vnic-profile-name')
nic.network = None # required so no mix of old-new api
nic.update()

example of ovirt-engine-sdk-java:
VnicProfile profile = api.getVnicProfiles().get("vnic-profile-name");
VM vm = api.getVMs().get("vm1");
VMNIC vnic = vm.getNics().get("nic1");
vnic.setVnicProfile(profile);
vnic.setNetwork(null);
vnic.update();

Moti, 

This nullification is not trivial to end user.
When user uses update in other places - he just sets needed parameters.
In this case how user will know that should nullify network? You can see that your first users that are familiar with API were confused.
Maybe it worth to add some RN for it?

After additional testing with the nic.update() api, i've noticed that regardless of the vnic profile id/network name being provided in the parameters, the result of that action will shuffle the vnic profile assigned to the nic.

The engine logic for backward compatibility of the vm/template nic api should be fixed in the following manner:

1. If network name is provided, and unchanged - the vnic profile id from the parameters is used.
2. If the network name is provided and changed, use it instead of the vnic profile id.

In this way the engine assumes that only proactive changes should be considered when finding a vnic profile id for the given network.

Verified in ovirt-engine-3.4.0-0.7.beta2.el6.noarch

This bug is referenced in ovirt-engine-3.4.0-beta3 logs. Moving to ON_QA

Verified in ovirt-engine-3.4.0-0.11.beta3.el6.noarch

Closing as part of 3.4.0