Red Hat Bugzilla – Bug 1560422
The global amount of Octavia loadbalancers is constrained by the service project quotas
Last modified: 2018-06-27 11:49:36 EDT
Description of problem: LB creation creates neutron ports, security groups and instances(cores, RAM, keypairs, etc). Those objects, when created with LB create command execution are needed not to be omitted while planning the cloud with Octavia. Possible solutions 1 of 3 : a- Agreed quota numbers b- Unlimited quota numbers c- Documentation of the effect of LB creation on the resources in neutron and nova so the operator could include that in the cloud planning and services quotas configuration.
Let's double check that instances and other quotas are taken from the 'services' tenant, and check what is the default quota in that tenant.
I was able to reproduce this issue, and indeed we are being blocked by 'service' project quota. Octavia creates Amphorae (service VMs) under an operator configured project (tenant). In TripleO, we currently use 'service' project by default. Since booting Amphorae consume the project quota, this essentially result a very low (around 10) global upper constraint for loadbalancers amount. This is in opposed to how quotas normally being used in openstack. To conclude: When user 'test' creates a loadbalancer in project 'xyz': 1. Loadbalancer related quota is being consumed for project xyz' (expected). 2. ports, cores, instances, ram and security groups quota is being consumed for project 'service', which will eventually prevent users from *any* project to create loadbalancers. Even if they did not fully consume their loadbalancer related project quota. To fix this: We need to address the 'service' project as a system project. Thus, we cannot be limited by project quotas for Octavia VMs. We need to set '-1' for the following quotas (in the 'service project only): 1. ports 2. cores 3. instances 4. ram 5. security groups
Created attachment 1433219 [details] example when we get blocked by security groups quota for the service project
Current default quota numbers: ports 500 cores 20 instances 10 ram 51200 security groups 10
To resolve after deployment, run the following command
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2018:2086