Hide Forgot
Created attachment 924243 [details] engine logs Description of problem: Setting a range of MACs for use by using engine-config -s MacPoolRanges does not allow full range to be utilized. For example, setting the following range: [root@gadi-rhevm ~]# engine-config -g MacPoolRanges MacPoolRanges: 00:1a:4a:c0:69:00-00:1a:4a:c0:69:01 version: general Should allow 2 NICs to be created with auto-assigned MACs, yet only one can be created. Version-Release number of selected component (if applicable): ovirt-engine-3.5.0-0.0.master.20140722232058.git8e1babc.el6.noarch How reproducible: 100% Steps to Reproduce: 1. Set MAC Pool Range to a known range using engine-config (and restart ovirt-engine service) 2. Attempt to add number of nics equal to range size Actual results: Fails to add the last NIC (range is actually 1 less than expected) Expected results: Should allow full range to be utilized, or documented that one of the edges of the range is not inclusive Additional info:
Gil, why is this marked as a blocker for the 3.5 release? Is it simply because it's blocking automation? Otherwise, on a typical deployment there won't be 2 MAC addresses, there will be 10,000 out of which one won't be useable. So doesn't sound like a blocker to me.
Yes, automation blocker is the main reason to block it. I agree this is not a typical deployment use case, but currently we lost our visibility on some QE jobs.
In the future, it might be a good idea to make test jobs less fragile. While it is a bug that one MAC address out of a range isn't usable, it should be moderately minor. I don't see a reason why critical automatic tests would depend on 100% utilization of a freakishly small MAC range in order to run.
Verified on - 3.5.0-0.10.master.el6ev
oVirt 3.5 has been released and should include the fix for this issue.