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$
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.