stale L2 policy persists even on its fail creation

Bug #1407321 reported by puppet-py
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Group Based Policy
Fix Released
High
Robert Kukura

Bug Description

If a L3-policy is first configured/created using default ip-pool, then any new L2policy creation will fail if the L2policy wants to use default(auto-created) L3policy. This is due to conflicting ip-pools and it is as per design.
However since the L2policy creation has faiuled, which means configuration should be roll-backed, but it fails and leaves behind the L2policy as a stale entry in the dbase

See the following steps that leads to the bug:

test@localhost:~/devstack$ gbp l2policy-list
test@localhost:~/devstack$
test@localhost:~/devstack$ gbp l3policy-list
test@localhost:~/devstack$
test@localhost:~/devstack$ gbp l3policy-create L3-pool-1
Created a new l3_policy:
+----------------------+--------------------------------------+
| Field | Value |
+----------------------+--------------------------------------+
| description | |
| external_segments | {} |
| id | 583eb3f8-6ac0-4d12-b728-7d4d1c9978f8 |
| ip_pool | 10.0.0.0/8 |
| ip_version | 4 |
| l2_policies | |
| name | L3-pool-1 |
| routers | 735cb512-d510-4050-9498-e68ab825fe99 |
| shared | False |
| subnet_prefix_length | 24 |
| tenant_id | 3b4eb7e4327b4d90be39288b2e8dd163 |
+----------------------+--------------------------------------+
test@localhost:~/devstack$
test@localhost:~/devstack$
test@localhost:~/devstack$ gbp l2policy-create L2-vlan-A
Bad Request (HTTP 400) (Request-ID: req-2e73714f-0bb2-4360-9c6f-ac26a4a6d20d)
test@localhost:~/devstack$
test@localhost:~/devstack$ gbp l2policy-list
+--------------------------------------+-----------+-------------+--------------+
| id | name | description | l3_policy_id |
+--------------------------------------+-----------+-------------+--------------+
| 1e1ecb5e-7490-4ba5-9cc6-73a26edc8a5c | L2-vlan-A | | |
+--------------------------------------+-----------+-------------+--------------+
test@localhost:~/devstack$

affects: group-based-policy-client → group-based-policy
Changed in group-based-policy:
milestone: none → kilo-gbp-1
assignee: nobody → Robert Kukura (rkukura)
Changed in group-based-policy:
importance: Undecided → High
status: New → Confirmed
tags: added: juno-backport-potential
Revision history for this message
Robert Kukura (rkukura) wrote :

I'm not clear on why the "gbp l2policy-create L2-vlan-A" command is failing. As I understand it, it should succeed, creating a new L3P named "default", since no L3P was explicitly passed in, and no default L2P yet exists.

Also, I'm not sure what you mean by "conflicting ip-pools". I believe a single tenant should be allowed to create as many distinct L3P objects as they like, even if the ip pools of these overlap. Any interaction between distinct L3Ps should be NATed so, overlap shouldn't matter.

Revision history for this message
puppet-py (jbanerje) wrote :

We are addressing two issues here:
1. If L2Policy is created with a default L3Policy, then the "default" L3Policy creation will fail due to over-lapping ip-pools, provided there already exists another L3Policy which is using the same ip-pool as that of the default.
The neutron logs clearly says that overlapping ip-pool is the reason for the failure.. please see below

test@localhost:~/devstack$ gbp l2policy-create new
Bad Request (HTTP 400) (Request-ID: req-3dd89e37-b136-4a52-9bad-45f333e197e7)
test@localhost:~/devstack$

2015-02-04 11:34:56.647 19570 DEBUG gbpservice.neutron.db.grouppolicy.group_policy_db [req-3dd89e37-b136-4a52-9bad-45f333e197e7 None] gbpservice.neutron.services.grouppolicy.plugin.GroupPolicyPlugin method get_l3_policies called with arguments (<neutron.context.Context object at 0x7f3e2cfe3f90>, {'tenant_id': [u'b3094e3ded7e4d6ea7b91b3641214a7a']}, None, None, None, None, False) {} wrapper /opt/stack/neutron/neutron/common/log.py:33
2015-02-04 11:34:56.654 19570 INFO neutron.api.v2.resource [req-3dd89e37-b136-4a52-9bad-45f333e197e7 None] create failed (client error): IP Pool 10.0.0.0/8 overlaps with one of the existing L3P for the same tenant [u'10.0.0.0/8'].

2. Although L2Policy create resulted in client-error, as a user it is very well expected that the L2Policy object has NOT got created since the cmd has failed. But we still create the L2P object without null "network-id" and L3policy_id.

test@localhost:~/devstack$ gbp l2policy-show new
+----------------------+--------------------------------------+
| Field | Value |
+----------------------+--------------------------------------+
| description | |
| id | e0328344-3455-4d38-8942-2ba5166575d8 |
| l3_policy_id | |
| name | new |
| network_id | |
| policy_target_groups | |
| shared | False |
| tenant_id | b3094e3ded7e4d6ea7b91b3641214a7a |
+----------------------+--------------------------------------+
test@localhost:~/devstack$

Changed in group-based-policy:
milestone: kilo-gbp-1 → kilo-gbp-2
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to group-based-policy (master)

Fix proposed to branch: master
Review: https://review.openstack.org/161619

Changed in group-based-policy:
status: Confirmed → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to group-based-policy (master)

Reviewed: https://review.openstack.org/161619
Committed: https://git.openstack.org/cgit/stackforge/group-based-policy/commit/?id=75dd238e507e86d3dbe6436265314d565906b268
Submitter: Jenkins
Branch: master

commit 75dd238e507e86d3dbe6436265314d565906b268
Author: Robert Kukura <email address hidden>
Date: Wed Mar 4 22:02:01 2015 -0500

    Properly handle driver exceptions during postcommit

    If any exception is raised by a driver's create_<resource>_postcommit
    method, the partially-created resource is deleted before returning the
    exception to the client.

    If any exception is raised by a driver's delete_<resource>_postcommit
    method, the exception is logged, but is not returned to the client.

    Also, the log messages are made more consistent and readable.

    Closes-bug: 1407321
    Partial-bug: 1416177
    Change-Id: I7c3096ae436f23d68d695b813f7d8d0b2588dbfe

Changed in group-based-policy:
status: In Progress → Fix Committed
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to group-based-policy (stable/juno)

Fix proposed to branch: stable/juno
Review: https://review.openstack.org/164914

Changed in group-based-policy:
status: Fix Committed → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to group-based-policy (stable/juno)

Reviewed: https://review.openstack.org/164914
Committed: https://git.openstack.org/cgit/stackforge/group-based-policy/commit/?id=c6eaae187283c8d2a738a5eb27d1532cae34a5d7
Submitter: Jenkins
Branch: stable/juno

commit c6eaae187283c8d2a738a5eb27d1532cae34a5d7
Author: Robert Kukura <email address hidden>
Date: Wed Mar 4 22:02:01 2015 -0500

    Properly handle driver exceptions during postcommit

    If any exception is raised by a driver's create_<resource>_postcommit
    method, the partially-created resource is deleted before returning the
    exception to the client.

    If any exception is raised by a driver's delete_<resource>_postcommit
    method, the exception is logged, but is not returned to the client.

    Also, the log messages are made more consistent and readable.

    Closes-bug: 1407321
    Partial-bug: 1416177
    Change-Id: I7c3096ae436f23d68d695b813f7d8d0b2588dbfe
    (cherry picked from commit 75dd238e507e86d3dbe6436265314d565906b268)

tags: added: in-stable-juno
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.