GBP: Existing L3Policy results in failure to create PTG with default L2Policy

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

Bug Description

A user creates an L3Policy with a subnet 10.0.x.y/z, where x=0-to-254,y=0-to-254, z>8, not being aware of a default ip-pool range of default L3Policy

Now the user wants to create a PTG using default L2Policy, that create will fail(Exceptions are thrown), although PTG still gets created will null-subnet & L2Policy (ideally we should NOT have allowed this creation.. please refer the bug: 1416177).

Reason behind the failure: Default L2Policy results in default L3Policy which in turn uses a default(pre-defined) ip-pool range which supernets the above user-created L3Policy. Since its overlapping the L3Policy creation fails and the effect cascades

-- We should ideally block the default ip-pool range so that user can avoid creation of over-lapping IP
-- We should reduce the default ip-block size(/8), since it is indeed quite a large IP range, not sure how much applicable for an Enterprise customer

puppet-py (jbanerje)
description: updated
Changed in group-based-policy:
assignee: nobody → Robert Kukura (rkukura)
status: New → Confirmed
importance: Undecided → Medium
milestone: none → kilo-gbp-2
importance: Medium → High
tags: added: juno-backport-potential
Changed in group-based-policy:
milestone: kilo-gbp-2 → kilo-gbp-3
Changed in group-based-policy:
milestone: kilo-gbp-3 → next
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/224293
Committed: https://git.openstack.org/cgit/stackforge/group-based-policy/commit/?id=7acac86b65f360b1b0dc230cc944c96f1366d9dd
Submitter: Jenkins
Branch: master

commit 7acac86b65f360b1b0dc230cc944c96f1366d9dd
Author: Robert Kukura <email address hidden>
Date: Wed Sep 16 14:50:26 2015 -0400

    Handle concurrent implicit L3P creation

    In the implicit_policy driver, when creating a default L3 policy,
    raise DefaultL3PolicyAlreadyExists if an L3 policy named 'default'
    already exists.

    If DefaultL3PolicyAlreadyExists is raised when the implicit_policy
    driver attempts to create the default L3 policy for a tenant, query
    again to see if a default L3 policy has been concurrently created, and
    if so, use that. This requires adding local_api wrappers for
    postcommit group policy resource CRUD operations called in the
    implicit_policy driver, so that clean DB sessions are used.

    Also, fix the resource_mapping driver's
    delete_policy_target_group_postcommit to gracefully handle partially
    constructed states, such as a null L2 policy or a subnet not attached
    to a router.

    Closes-bug: 1462024
    Partial-bug: 1417312

    Change-Id: I09f29eef22edb45290070aae30e97c93c77ea341

Revision history for this message
Robert Kukura (rkukura) wrote :

Jishnu should re-test this once the patch above is back-ported to juno.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to group-based-policy (stable/kilo)

Fix proposed to branch: stable/kilo
Review: https://review.openstack.org/228607

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to group-based-policy (stable/kilo)

Reviewed: https://review.openstack.org/228607
Committed: https://git.openstack.org/cgit/stackforge/group-based-policy/commit/?id=4fcd843eff4f19d1d8c77ba30c1d9f0bac06b9c8
Submitter: Jenkins
Branch: stable/kilo

commit 4fcd843eff4f19d1d8c77ba30c1d9f0bac06b9c8
Author: Robert Kukura <email address hidden>
Date: Wed Sep 16 14:50:26 2015 -0400

    Handle concurrent implicit L3P creation

    In the implicit_policy driver, when creating a default L3 policy,
    raise DefaultL3PolicyAlreadyExists if an L3 policy named 'default'
    already exists.

    If DefaultL3PolicyAlreadyExists is raised when the implicit_policy
    driver attempts to create the default L3 policy for a tenant, query
    again to see if a default L3 policy has been concurrently created, and
    if so, use that. This requires adding local_api wrappers for
    postcommit group policy resource CRUD operations called in the
    implicit_policy driver, so that clean DB sessions are used.

    Also, fix the resource_mapping driver's
    delete_policy_target_group_postcommit to gracefully handle partially
    constructed states, such as a null L2 policy or a subnet not attached
    to a router.

    Closes-bug: 1462024
    Partial-bug: 1417312

    Conflicts:
     gbpservice/network/neutronv2/local_api.py
     gbpservice/neutron/services/grouppolicy/drivers/resource_mapping.py

    Change-Id: I09f29eef22edb45290070aae30e97c93c77ea341
    (cherry picked from commit 7acac86b65f360b1b0dc230cc944c96f1366d9dd)

tags: added: in-stable-kilo
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/228684

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to group-based-policy (stable/juno)

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

commit 9f3bef975ed2f0f56edd99f36121bbd9f1c58c72
Author: Robert Kukura <email address hidden>
Date: Wed Sep 16 14:50:26 2015 -0400

    Handle concurrent implicit L3P creation

    In the implicit_policy driver, when creating a default L3 policy,
    raise DefaultL3PolicyAlreadyExists if an L3 policy named 'default'
    already exists.

    If DefaultL3PolicyAlreadyExists is raised when the implicit_policy
    driver attempts to create the default L3 policy for a tenant, query
    again to see if a default L3 policy has been concurrently created, and
    if so, use that. This requires adding local_api wrappers for
    postcommit group policy resource CRUD operations called in the
    implicit_policy driver, so that clean DB sessions are used.

    Also, fix the resource_mapping driver's
    delete_policy_target_group_postcommit to gracefully handle partially
    constructed states, such as a null L2 policy or a subnet not attached
    to a router.

    Closes-bug: 1462024
    Partial-bug: 1417312

    Conflicts:
     gbpservice/network/neutronv2/local_api.py
     gbpservice/neutron/services/grouppolicy/drivers/implicit_policy.py

    Change-Id: I09f29eef22edb45290070aae30e97c93c77ea341
    (cherry picked from commit 7acac86b65f360b1b0dc230cc944c96f1366d9dd)
    (cherry picked from commit 4fcd843eff4f19d1d8c77ba30c1d9f0bac06b9c8)

tags: added: in-stable-juno
Revision history for this message
Robert Kukura (rkukura) wrote :

The fix for bug 1416177 has been back-ported, and should resolve the null subnet part of this issue.

I'm not convinced we should block attempts to create any L3 policy whose ip_pool overlaps the default L3P ip_pool attribute value. Its really up to the user whether they want to use default L3Ps at all, and if so, what CIDR they use. I expect tenants will either use implicit or explicit L3P creation, and not try to mix these. If the user creates an L3P that overlaps the default CIDR, and then wants to use implicit L2P creation when creating PTGs, they can explicitly create an L3P named 'default' that uses a different CIDR, and then this L3P will be used for implicit L2Ps for subsequent PTGs.

I do kind of agree we should reduce the default ip_pool value from a /8 to maybe a /16. In doing so, we could also pick something other than 10.0.0.0/16 to reduce the chance of previous explicitly-created L3Ps colliding with default L3P creation.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers