Bug 1308336 - [SetupNetworks old API] update network to have IP cause the network to be out of sync
Summary: [SetupNetworks old API] update network to have IP cause the network to be out...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Network
Version: 3.6.3.1
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ovirt-3.6.3
: 3.6.3.2
Assignee: Martin Mucha
QA Contact: Michael Burman
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-02-14 11:53 UTC by Meni Yakove
Modified: 2016-02-18 11:11 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-02-18 11:11:54 UTC
oVirt Team: Network
Embargoed:
rule-engine: ovirt-3.6.z+
rule-engine: blocker+
ylavi: planning_ack+
danken: devel_ack+
myakove: testing_ack+


Attachments (Terms of Use)
content of my request (5.53 KB, text/plain)
2016-02-16 09:32 UTC, Martin Mucha
no flags Details


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 53314 0 master MERGED core: custom parameters couldn't be updated and wasnt reported 2016-02-16 10:11:58 UTC
oVirt gerrit 53573 0 ovirt-engine-3.6 MERGED core: custom parameters couldn't be updated and wasnt reported 2016-02-16 11:56:26 UTC
oVirt gerrit 53575 0 ovirt-engine-3.6.3 MERGED core: custom parameters couldn't be updated and wasnt reported 2016-02-16 11:59:43 UTC

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


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