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

Bug 1216081

Summary: [Neutron integration][webadmin] Networks with valid input for CIDR created without subnet and with error:Error while executing action: may not be null
Product: [oVirt] ovirt-engine Reporter: Michael Burman <mburman>
Component: Frontend.WebAdminAssignee: Marcin Mirecki <mmirecki>
Status: CLOSED CURRENTRELEASE QA Contact: Michael Burman <mburman>
Severity: high Docs Contact:
Priority: high    
Version: ---CC: bazulay, bugs, danken, gklein, lsurette, mgoldboi, mperina, rbalakri, srevivo, ykaul, ylavi
Target Milestone: ovirt-4.0.1Keywords: Regression
Target Release: ---Flags: ykaul: ovirt-4.0.z+
rule-engine: blocker+
rule-engine: planning_ack+
rule-engine: devel_ack+
rule-engine: testing_ack+
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: ovirt-engine-4.0.0.5 Doc Type: Bug Fix
Doc Text:
Add network operation was not executed completely when the network was to be created also on an external provider and a subnet was added. The operation added the network, added it to the external provider, but failed to create the subnet. This patch fixed this. The add operation also creates a subnet now.
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-07-19 06:24:59 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:
Bug Depends On:    
Bug Blocks: 1345969    
Attachments:
Description Flags
screenshots+engine log none

Description Michael Burman 2015-04-28 12:59:44 UTC
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.

Comment 1 Lior Vernia 2015-04-29 11:32:27 UTC
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.

Comment 2 Michael Burman 2015-04-29 11:36:11 UTC
Lior, if it is caused by BZ 1012881, please let me know, because i have moved this bug to verified.

Comment 3 Lior Vernia 2015-04-29 11:46:07 UTC
Don't worry Michael, I think it's only caused by the fix to Bug 1012881 - that one should remain VERIFIED no matter what.

Comment 4 Michael Burman 2015-04-29 11:56:06 UTC
Ok thank you, great.

Comment 5 Barak 2015-05-10 13:23:13 UTC
Oved, does this issue effects also other providers (not Neutron) ?

Comment 6 Oved Ourfali 2015-05-10 13:33:26 UTC
(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.

Comment 7 Red Hat Bugzilla Rules Engine 2015-09-22 07:43:35 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 8 Dan Kenigsberg 2015-09-24 08:17:44 UTC
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

Comment 9 Red Hat Bugzilla Rules Engine 2015-09-24 08:17:45 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 10 Red Hat Bugzilla Rules Engine 2015-10-19 10:51:44 UTC
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.

Comment 11 Yaniv Lavi 2015-10-29 12:14:31 UTC
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.

Comment 12 Yaniv Lavi 2015-11-26 23:58:30 UTC
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.

Comment 13 Eliraz Levi 2015-12-01 10:12:16 UTC
It seems like the only network provider currently exist is open stack.

Comment 14 Yaniv Lavi 2015-12-01 11:15:11 UTC
I thought we needed check if this affects other flows as well?

Comment 15 Dan Kenigsberg 2015-12-06 11:15:31 UTC
Per Eliraz, no other flows are affected. The "Neutron intergration" qualifier is in place.

Comment 17 Sandro Bonazzola 2016-05-02 09:54:50 UTC
Moving from 4.0 alpha to 4.0 beta since 4.0 alpha has been already released and bug is not ON_QA.

Comment 18 Yaniv Lavi 2016-05-23 13:16:33 UTC
oVirt 4.0 beta has been released, moving to RC milestone.

Comment 19 Yaniv Lavi 2016-05-23 13:22:47 UTC
oVirt 4.0 beta has been released, moving to RC milestone.

Comment 20 Martin Perina 2016-06-10 15:02:14 UTC
Changing to MODIFIED as it's included in today's 4.0.4 build

Comment 21 Michael Burman 2016-06-13 08:22:31 UTC
Verified on - 4.0.0.4-0.1.el7ev

Comment 22 Michael Burman 2016-06-14 04:45:54 UTC
Tis bug was verified, why patches still coming up?

Comment 23 Marcin Mirecki 2016-06-14 05:36:31 UTC
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.

Comment 24 Michael Burman 2016-06-14 05:42:28 UTC
Ok, thank you Marcin, in that case moving back to POST.

Comment 25 Red Hat Bugzilla Rules Engine 2016-06-14 05:42:35 UTC
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.

Comment 26 Marcin Mirecki 2016-06-14 08:53:45 UTC
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)

Comment 27 Dan Kenigsberg 2016-06-20 07:33:46 UTC
the class exception fix got merged into ovirt-engine-4.0.0.5

Comment 28 Michael Burman 2016-06-20 07:47:25 UTC
Verified on - 4.0.0.5-0.1.el7ev

Comment 29 Sandro Bonazzola 2016-07-19 06:24:59 UTC
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/