I see an issue when running Rally tests concurrently which creates policy target groups in parallel. I see the following error returned by the create policy target group API
5-83c6-4996-afa8-d602b48900f1 | ITER: 19 END: Error BadRequest: IP Pool 10.0.0.0/8 overlaps with one of the existing L3P for the same tenant [u'10.0.0.0/8'].
k/scenarios/gbp/gbp.py\", line 23, in test_gbp\n self._create_policy_target_group(pt_group_name)\n File \"/home/akalambu/rally/local/lib/python2.7/site-packages/rally/benchmark/scenarios/base.py\", line 262, in func_atomic_actions\n f = func(self, *args, **kwargs)\n File \"/home/akalambu/rally/local/lib/python2.7/site-packages/rally/plugins/openstack/scenarios/gbp/utils.py\", line 157, in _create_policy_target_group\n self.clients(\"gbp\").create_policy_target_group(body)\n File \"/home/akalambu/rally/local/lib/python2.7/site-packages/gbpclient/v2_0/client.py\", line 97, in with_params\n ret = self.function(instance, *args, **kwargs)\n File \"/home/akalambu/rally/local/lib/python2.7/site-packages/gbpclient/v2_0/client.py\", line 266, in create_policy_target_group\n return self.post(self.policy_target_groups_path, body=body)\n File \"/home/akalambu/rally/local/lib/python2.7/site-packages/gbpclient/v2_0/client.py\", line 794, in post\n headers=headers, params=params)\n File \"/home/akalambu/rally/local/lib/python2.7/site-packages/gbpclient/v2_0/client.py\", line 720, in do_request\n self._handle_fault_response(status_code, replybody)\n File \"/home/akalambu/rally/local/lib/python2.7/site-packages/gbpclient/v2_0/client.py\", line 691, in _handle_fault_response\n exception_handler_v20(status_code, des_error_body)\n File \"/home/akalambu/rally/local/lib/python2.7/site-packages/gbpclient/v2_0/client.py\", line 64, in exception_handler_v20\n status_code=status_code)\nBadRequest: IP Pool 10.0.0.0/8 overlaps with one of the existing L3P for the same tenant [u'10.0.0.0/8'].\n"
Note from Sumeet for reference
Hi Ajay, Overlapping IP pools are not currently supported for the same
tenant with the default Neutron rendering. So when you create multiple
PTGs in parallel without specifying the L2P/L3P, the implicit workflow
tries to create a L3P with a default IP Pool (10.0.0.0/8 in this
case). The second PTG is trying to be created while the post-commit
for the first one has not finished yet. Hence you are seeing this
issue. I would appreciate if you can file a bug for this, since we
should explore what is a better workflow in this case.
It looks to me like this can be resolved by catching this exception and then doing another query to see if a concurrent request has created a default L3P for the tenant, and if so, using it.
This will also resolve the REVISIT regarding concurrency, as long as overlapping L3Ps are disallowed. But once that restriction is removed, this exception will no longer be raised and we'll need some other mechanism, such as the DB table mentioned in the REVISIT, to prevent multiple default L3Ps from being created for a tenant.