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

[puppet-py]

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

[OpenStack Infra (hudson-openstack)]

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

[Robert Kukura (rkukura)]

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

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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)

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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)

[Robert Kukura (rkukura)]

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.