Quotas exist in Designate for various resources, these are configurable by an operator globally, as well as on a per-tenant basis.
Users can view their quotas with a simple API call:
GET /v2/quotas/ HTTP/1.1
Accept: application/json
Content-Type: application/json
Response:
HTTP/1.1 200 OK
Content-Type: application/json; charset=UTF-8
X-Openstack-Request-Id: req-bfcd0723-624c-4ec2-bbd5-99e985efe8db
{
"api_export_size": 1000,
"recordset_records": 20,
"zone_records": 500,
"zone_recordsets": 500,
"zones": 500
}
Administrators with the ability to use the X-Auth-All-Projects
header
can view the quotas of any user by making a similar API call to
/v2/quotas/tenant
.
Quota | Description | Default |
zones | The number of zone allowed per tenant | 10 |
Quota | Description | Default |
zone_recordsets | Number of recordsets allowed per zone | 500 |
zone_records | Number of records allowed per zone | 500 |
recordset_records | Number of records allowed per recordset | 20 |
Quota | Description | Default |
api_export_size | Number of recordsets allowed in a zone export | 1000 |
All of the quotas above can be set as a default for all users by editing the
[DEFAULT]
configuration section, and setting each quota with
quota_$name
. for example:
[DEFAULT]
########################
## General Configuration
########################
quota_zones = 500
quota_zone_recordsets = 500
quota_zone_records = 500
quota_recordset_records = 20
quota_api_export_size = 1000
These quotas can be edited via API on a per-tenant basis. An administrator
can edit quotas for any tenant, but they must supply the
X-Auth-All-Projects
header, and have permission to use it, they’ll also
need the set-quotas
permission in policy.json
. For example, an
admin setting the zones quota for tenant X would look like:
PATCH /v2/quotas/tenantX HTTP/1.1
Accept: application/json
Content-Type: application/json
X-Auth-All-Projects: True
{
"zones": 100
}
The response would be:
HTTP/1.1 200 OK
Content-Type: application/json; charset=UTF-8
X-Openstack-Request-Id: req-bfcd0723-624c-4ec2-bbd5-99e985efe8db
{
"api_export_size": 1000,
"recordset_records": 20,
"zone_records": 500,
"zone_recordsets": 500,
"zones": 100
}
Although Designate API can accept arbitrary strings as Tenant ID to set the
quota for, actual enforcement of quota will be performed only when the
tenant ID that was set is matching the project-id
in the request
that attempts to create a resource.
To have some guards against possible mistakes when setting quotas, the following option can be enabled in the Designate configuration file:
[service:api]
quotas_verify_project_id = True
Additionally, the [keystone]
section in the configuration file might have
to be populated with keystoneauth
Session- and Adapter-related options
specifying how to connect to Keystone and find appropriate Keystone endpoint
to perform requests against
(see keystoneauth documentation
for more details). Example:
[keystone]
cafile = /path/to/ca/bundle
valid_interfaces = internal,public
region_name = RegionWest
With those settings enabled, Designate will use the incoming token of user
performing the PATCH /v2/quotas/tenantX
request to make a best effort
attempt to verify that the requested Tenant ID (tenantX
part of the request)
is indeed a valid Project ID in Keystone.
As a result of this verification, the PATCH /v2/quotas/tenantX
request
may return additional errors in case of:
[keystone]
section) - 504
error is returned400
is returnedThe situation when the authorization with incoming token fails is ignored. For best results ensure that the user setting quotas is allowed to list projects in Keystone.
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.