Quota Policy Syntax

The following topic describes compartment quota policy syntax.

Three types of quota policy statements are available:

  • set: Sets the maximum number of a cloud resource that can be used for a compartment.
  • unset: Resets quotas back to the default service limits.
  • zero: Removes access to a cloud resource for a compartment.
Quota policy statements have the following format:
Quota policy set statement diagram
Quota policy unset statement diagram
Quota policy zero statement diagram

The language components for a quota policy statement are:

  • The action keyword, which corresponds to the type of quota being defined. The keyword can be set, unset, or zero.
  • The name of the service family; for example: compute-core.
  • The quota or quotas keyword.
  • The name of the quota, which varies by service family. For example, a valid quota in the compute-core family is standard-e4-core-count.
    • You can also use wildcards to specify a range of names. For example, "/standard*/" matches all Compute quotas that start with the phrase "standard."
  • For set statements, the value of the quota.
  • The compartment that the quota covers.
  • An optional condition. For example, where request.region = 'us-phoenix-1'. Currently supported conditionals are request.region and request.ad.

Also see Sample Quotas for some common usage examples.

Scope

Quotas can have different scopes, and work at the availability domain, the region, or globally. The following are some important points to understand about scope when working with compartment quotas:

  • When setting a quota at the availability domain (AD) level, the quota is allocated to each AD. So, for example, setting a quota of 120 OCPUs on a compartment actually sets a limit of 120 OCPUs per AD. To target a specific AD, use the request.ad parameter in the where clause.

  • Regional quotas apply to each region. See Sample Quotas for an example of a regional quota.

  • Usage for subcompartments counts toward usage for the main compartment.

For more information, see Regions and Availability Domains.

Permissions and Nesting

Compartment quotas can be set on the root compartment. An administrator (who must be able to manage quotas on the root compartment) can set quotas on their own compartments, and any child compartments. Quotas set on a parent compartment override quotas set on child compartments. This way, an administrator of a parent compartment can create a quota on a child compartment that cannot be overridden by the child.

Note

Policies that target nested compartments are written like the following:
set compute quota standard-e4-core-count to 10 in compartment parent:child:another_child

Quota Evaluation and Precedence

The following rules apply when quota statements are evaluated:
  • Within a policy, quota statements are evaluated in order, and later statements supersede previous statements that target the same resource.
  • In cases where more than one policy is set for the same resource, the most restrictive policy is applied.
  • Service limits always take precedence over quotas. Although it is possible to specify a quota for a resource that exceeds the service limit for that resource, the service limit is still be enforced.

Wildcards

Some quota family have many resources, for example, the Compute and Database quota family are composed of many quotas. Quota name wildcards can be used in such cases to specify a range of names. For example, "/standard*/" matches all Compute quotas that start with the phrase "standard."

This example uses a wildcard to allocate all exadata resources to the ProductionApp compartment:

zero database quota /*exadata*/ in tenancy
unset database quota /*exadata*/ in compartment ProductionApp

Meanwhile, this example uses a wildcard that sets all quotas that have the phrase standard in the compute-core family to 2:

set compute-core quotas /standard*/ to 2 in compartment MyCompartment