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

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

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

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

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)

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

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)

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.