Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1101326

Summary: setting up a network with the blockingdhcp option makes it non-blocking and vice-versa
Product: [Retired] oVirt Reporter: Antoni Segura Puimedon <asegurap>
Component: vdsmAssignee: Antoni Segura Puimedon <asegurap>
Status: CLOSED CURRENTRELEASE QA Contact: Gil Klein <gklein>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 3.4CC: acathrow, bazulay, danken, gklein, iheim, mgoldboi, yeylon
Target Milestone: ---   
Target Release: 3.4.2   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: network
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-06-11 06:44:44 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1114269    

Description Antoni Segura Puimedon 2014-05-26 23:20:14 UTC 
Description of problem:
network addition verbs accept a network definition dictionary that allows to 
specify, among other things, the ip configuration and the booting protocol.

In case the booting protocol for the network is DHCP, an option was made
available called 'blockingdhcp' that is supposed to give the user the option
to wait for dhcp addressing before returning from the network configuring verb,
and the default was set to be non-blocking, i.e., asynchronous.

The problem lies that as part of the network refactorings, the default
regressed into being always blocking and the blockingdhcp option became a flag
for setting its opposite, i.e., for performing the dhcp addressing
asynchronously.

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


How reproducible: 100%


Steps to Reproduce:
1. vdsClient -s 0 addNetwork bridge=foo nics= bootproto=dhcp

Actual results:
Returns as successful even though the dhcp addressing cannot succeed (due to it
being a network consisting solely of an isolated bridge) because taking up the
network was performed asynchronously.

Expected results:
The network addition fails.

Additional info:
The steps above are the simplest way to reproduce, but the opposite is true,
if you rely on having the operation respect blockingdchp so that when it
returns successfully the device already has dhcp addressing, that will fail
as well.
Comment 1 Sandro Bonazzola 2014-06-11 06:44:44 UTC 
This is an automated message

oVirt 3.4.2 has been released:
 * should fix your issue
 * should be available at your local mirror within two days.

If problems still persist, please make note of it in this bug report.