Created attachment 1019659 [details] screenshots+engine log Description of problem: [Neutron integration][webadmin] Networks with valid input for CIDR created without subnet and with error:Error while executing action: may not be null Version-Release number of selected component (if applicable): 3.6.0-0.0.master.20150412172306.git55ba764.el6 How reproducible: 100 Steps to Reproduce: 1. Working setup with neutron as external network provider configured 2. Go to Networks > New > enter name for network and check Create on external provider check box. select your neutron provider. 3. Go to Subnet sub tab on the upper left and check Create subnet check box. enter name and valid CIDR address like: 1.1.1.0/24 or 2.2.0.0/16 4. Press 'ok' button to approve operation Actual results: Operation canceled Error while executing action: may not be null result- network created without subnet. on neutron network created without subnet as well. engine.log CanDoAction of action 'AddSubnetToProvider' failed for user admin@internal. Reasons: VAR__TYPE__SUBNET,VAR__ACTION__ADD,may not be null less /var/log/neutron/server.log 2015-04-28 08:41:13.540 1017 INFO neutron.wsgi [-] (1017) accepted ('10.35.161.138', 58537) 2015-04-28 08:41:13.566 1017 INFO urllib3.connectionpool [-] Starting new HTTP connection (1): 127.0.0.1 2015-04-28 08:41:13.768 1017 INFO urllib3.connectionpool [-] Starting new HTTP connection (1): 127.0.0.1 2015-04-28 08:41:14.017 1017 INFO neutron.plugins.ml2.db [req-e731b348-74e0-49fe-94c7-34f69bca79a4 None] Added segment 5b169357-c1eb-4d7b-b7d3-3dbb6056c67c of type vlan for network eab62c07-0f56-4866-a169-8faf4777d0d1 2015-04-28 08:41:14.037 1017 INFO neutron.wsgi [req-e731b348-74e0-49fe-94c7-34f69bca79a4 None] 10.35.161.138 - - [28/Apr/2015 08:41:14] "POST /v2.0/networks HTTP/1.1" 201 524 0.474617 Expected results: Should work as expected. Network should created with subnet if the input for CIDR is a valid network address. Additional info: Regression, used to work as expected.
This sounds like a problem with the frontend (NetworkModel) flushing the business entity to the backend without the subnet field. I suspect this regression was caused either by Bug 1012881, or by the management network role feature.
Lior, if it is caused by BZ 1012881, please let me know, because i have moved this bug to verified.
Don't worry Michael, I think it's only caused by the fix to Bug 1012881 - that one should remain VERIFIED no matter what.
Ok thank you, great.
Oved, does this issue effects also other providers (not Neutron) ?
(In reply to Barak from comment #5) > Oved, does this issue effects also other providers (not Neutron) ? It doesn't seem like that, but I'm not entirely familiar with the flow described above. Sounds to me like it should be examined by the network team, to find the root cause.
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.
Meni does this happen in the setup Network window, too? if the regression is limitted to Neutron, we can live with it (dur to athe workaround of using subnet) until 3.6.1
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
In oVirt testing is done on single release by default. Therefore I'm removing the 4.0 flag. If you think this bug must be tested in 4.0 as well, please re-add the flag. Please note we might not have testing resources to handle the 4.0 clone.
Can you please explain why you want this moved to 4.0? The flags need to be be changed after discussion. Moving back for now.
It seems like the only network provider currently exist is open stack.
I thought we needed check if this affects other flows as well?
Per Eliraz, no other flows are affected. The "Neutron intergration" qualifier is in place.
Moving from 4.0 alpha to 4.0 beta since 4.0 alpha has been already released and bug is not ON_QA.
oVirt 4.0 beta has been released, moving to RC milestone.
Changing to MODIFIED as it's included in today's 4.0.4 build
Verified on - 4.0.0.4-0.1.el7ev
Tis bug was verified, why patches still coming up?
I discovered a problem that was introduced by the previous patches. In some circumstances they could cause an exception. The new patch is a fix for this. I think the patch will need to be re-verified. I will add the test procedure against this condition later.
Ok, thank you Marcin, in that case moving back to POST.
Please include the following scenarios in the tests: - adding a network, select to add on external provider, add with/without subnet - adding a newwork, do NOT add on external provider (this was the scenario broken by the original patch)
the class exception fix got merged into ovirt-engine-4.0.0.5
Verified on - 4.0.0.5-0.1.el7ev
Since the problem described in this bug report should be resolved in oVirt 4.0.1 released on July 19th 2016, it has been closed with a resolution of CURRENT RELEASE. For information on the release, and how to update to this release, follow the link below. If the solution does not work for you, open a new bug report. http://www.ovirt.org/release/4.0.1/