Bug 1308336

Summary: [SetupNetworks old API] update network to have IP cause the network to be out of sync
Product: [oVirt] ovirt-engine Reporter: Meni Yakove <myakove>
Component: BLL.NetworkAssignee: Martin Mucha <mmucha>
Status: CLOSED CURRENTRELEASE QA Contact: Michael Burman <mburman>
Severity: high Docs Contact:
Priority: unspecified    
Version: 3.6.3.1CC: alkaplan, bugs, danken, mmucha, ylavi
Target Milestone: ovirt-3.6.3Keywords: Regression
Target Release: 3.6.3.2Flags: rule-engine: ovirt-3.6.z+
rule-engine: blocker+
ylavi: planning_ack+
danken: devel_ack+
myakove: testing_ack+
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-02-18 11:11:54 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:
Attachments:
Description Flags
content of my request none

Description Meni Yakove 2016-02-14 11:53:33 UTC 
Description of problem:
When updating network to have IP or change existing IP via old SetupNetworks API the operation succeed but the network is out of sync 

Version-Release number of selected component (if applicable):
rhevm-3.6.3.1-0.1.el6.noarch

How reproducible:
100%

Steps to Reproduce:
1. Create network and attach it to host NIC via SetupNetworks (UI)
2. Update the network via REST with old SetupNetworks API to have IP (See "Additional info")


Actual results:
Network is out of sync

Expected results:
Network is synced

Additional info:
2016-02-14 13:42:42,636 - MainThread - host_nics - DEBUG - Action request content is --  url:/ovirt-engine/api/hosts/9fd27d0a-8db7-4c6b-8ce0-9d9c04752445/nics/setupnetworks body:<action>
	<async>false</async>
	<grace_period>
		<expiry>10</expiry>
	</grace_period>
	<host_nics>
		<host_nic>
			<name>enp6s0</name>
			<network>
				<name>net_1</name>
			</network>
			<ip netmask="255.255.255.0" address="1.1.1.1"/>
			<boot_protocol>static</boot_protocol>
		</host_nic>
		<host_nic href="/ovirt-engine/api/hosts/9fd27d0a-8db7-4c6b-8ce0-9d9c04752445/nics/3026c222-a57c-4c92-a93b-ed7c3ca26d7b" id="3026c222-a57c-4c92-a93b-ed7c3ca26d7b">
			<actions>
				<link href="/ovirt-engine/api/hosts/9fd27d0a-8db7-4c6b-8ce0-9d9c04752445/nics/3026c222-a57c-4c92-a93b-ed7c3ca26d7b/detach" rel="detach"/>
				<link href="/ovirt-engine/api/hosts/9fd27d0a-8db7-4c6b-8ce0-9d9c04752445/nics/3026c222-a57c-4c92-a93b-ed7c3ca26d7b/attach" rel="attach"/>
			</actions>
			<name>enp4s0</name>
			<link href="/ovirt-engine/api/hosts/9fd27d0a-8db7-4c6b-8ce0-9d9c04752445/nics/3026c222-a57c-4c92-a93b-ed7c3ca26d7b/statistics" rel="statistics"/>
			<link href="/ovirt-engine/api/hosts/9fd27d0a-8db7-4c6b-8ce0-9d9c04752445/nics/3026c222-a57c-4c92-a93b-ed7c3ca26d7b/labels" rel="labels"/>
			<link href="/ovirt-engine/api/hosts/9fd27d0a-8db7-4c6b-8ce0-9d9c04752445/nics/3026c222-a57c-4c92-a93b-ed7c3ca26d7b/networkattachments" rel="networkattachments"/>
			<host href="/ovirt-engine/api/hosts/9fd27d0a-8db7-4c6b-8ce0-9d9c04752445" id="9fd27d0a-8db7-4c6b-8ce0-9d9c04752445"/>
			<network href="/ovirt-engine/api/networks/d8bcaf64-3ed4-469c-b701-b6b911d1459e" id="d8bcaf64-3ed4-469c-b701-b6b911d1459e"/>
			<mac address="00:14:5e:17:d0:38"/>
			<ip netmask="255.255.255.0" gateway="10.35.128.254" address="10.35.128.9"/>
			<boot_protocol>dhcp</boot_protocol>
			<speed>1000000000</speed>
			<status>
				<state>up</state>
			</status>
			<mtu>1500</mtu>
			<bridged>true</bridged>
			<custom_configuration>false</custom_configuration>
		</host_nic>
	</host_nics>
	<check_connectivity>true</check_connectivity>
	<connectivity_timeout>60</connectivity_timeout>
	<force>false</force>
</action>
Comment 1 Red Hat Bugzilla Rules Engine 2016-02-14 23:44:10 UTC 
This bug report has Keywords: Regression or TestBlocker.
Since no regressions or test blockers are allowed between releases, it is also being identified as a blocker for this release. Please resolve ASAP.
Comment 2 Martin Mucha 2016-02-15 16:58:22 UTC 
I think, that you cannot use:
<ip netmask="255.255.255.0" address="1.1.1.1"/>
mentioned in 'additional comments'. If you use that, nothing will fail, because schema is not validated(?), but there aren't such parameters in Ip element. That is defined:

<xs:complexType name="Ip">
    <xs:sequence>
      <xs:element maxOccurs="1" minOccurs="0" name="address" type="xs:string"/>
      <xs:element maxOccurs="1" minOccurs="0" name="gateway" type="xs:string"/>
      <xs:element maxOccurs="1" minOccurs="0" name="netmask" type="xs:string"/>
      <xs:element maxOccurs="1" minOccurs="0" name="version" type="xs:string"/>
    </xs:sequence>
  </xs:complexType>


so you must use:

<ip>
      <address>192.168.1.11</address>
      <gateway>192.168.1.12</gateway>
      <netmask>255.255.255.0</netmask>
    </ip>

In your example you're simply clearing setting all three values to null.
Comment 3 Meni Yakove 2016-02-16 08:10:17 UTC 
What do you mean "I cannot use"? this is what we are sending and it works.
We had an interface with network attached to it and we update the network to have IP (without gateway) and we sending address and netmask so how we clear those values?
Comment 4 Martin Mucha 2016-02-16 09:29:18 UTC 
(In reply to Meni Yakove from comment #3)
> What do you mean "I cannot use"? this is what we are sending and it works.
> We had an interface with network attached to it and we update the network to
> have IP (without gateway) and we sending address and netmask so how we clear
> those values?

I can be wrong (although I don't know where), you may be using it correctly and it may work for you (although I don't know how that would be possible). If it is the case, I'd be grateful if you can explain how is it possible ...

Why I think it wrong: 
Excerpt from api.xsd clearly specifies, that address, gateway … must be subelements and not parameters. I tried debug both ways yesterday, and it seemed, that if you don't use 'subelement' way, your data will be only ignored.

method to look at is: org.ovirt.engine.api.restapi.resource.BackendHostNicsResource#toParameters

I used this resource: 
POST http://localhost:8080/ovirt-engine/api/hosts/0543e921-835d-4a87-8ca4-5341eeee3e42/nics/setupnetworks

and if I made only change in ip configuration using: 
<ip address="192.168.1.11" gateway="192.168.1.12" netmask="255.255.255.0"/>

the SetupNetworkCommand is not even executed ~ as it fails to detect any changes (method "noChangesDetected").
Comment 5 Martin Mucha 2016-02-16 09:32:13 UTC 
Created attachment 1127545 [details]
content of my request
Comment 6 Martin Mucha 2016-02-16 13:22:44 UTC 
(In reply to Martin Mucha from comment #4)
> (In reply to Meni Yakove from comment #3)
> > What do you mean "I cannot use"? this is what we are sending and it works.
> > We had an interface with network attached to it and we update the network to
> > have IP (without gateway) and we sending address and netmask so how we clear
> > those values?
> 
> I can be wrong (although I don't know where), you may be using it correctly
> and it may work for you (although I don't know how that would be possible).
> If it is the case, I'd be grateful if you can explain how is it possible ...
> 
> Why I think it wrong: 
> Excerpt from api.xsd clearly specifies, that address, gateway … must be
> subelements and not parameters. I tried debug both ways yesterday, and it
> seemed, that if you don't use 'subelement' way, your data will be only
> ignored.
> 
> method to look at is:
> org.ovirt.engine.api.restapi.resource.BackendHostNicsResource#toParameters
> 
> I used this resource: 
> POST
> http://localhost:8080/ovirt-engine/api/hosts/0543e921-835d-4a87-8ca4-
> 5341eeee3e42/nics/setupnetworks
> 
> and if I made only change in ip configuration using: 
> <ip address="192.168.1.11" gateway="192.168.1.12" netmask="255.255.255.0"/>
> 
> the SetupNetworkCommand is not even executed ~ as it fails to detect any
> changes (method "noChangesDetected").

note: I wasn't correct. There's change in api between 3.6 and 4.0. In 3.6 correct syntax is exactly like meni described. Subelements are required from 4.0 on. Sorry for confusion.
Comment 7 Michael Burman 2016-02-17 13:46:04 UTC 
Verified on - 3.6.3.2-0.1.el6