Credentials
Reading and writing policies use different credentials:- Writing policies uses a partner client, because the request names the tenant. The examples call it
partnerClient. - Reading policies uses a tenant client, because the request has no tenant ID and applies to the tenant the token belongs to. The examples call it
tenantClient.
How policies are stored
A tenant has a list of policies and a revision number. Every successful change replaces the whole list and increments the revision. The main policy is the usage policy, identified bynamespace.cloud.compute.v1beta.UsagePolicy.
Its settings are stored as a JSON string in the policy’s value:
{}, at revision 1.
Set a tenant’s policies
To give a tenant a fixed set of limits, for example when a customer picks a plan, send the complete policy list. It replaces whatever the tenant had before, so there is no need to read the current policies first.Read a tenant’s policies
Change one setting and keep the rest
Setting policies replaces the whole list, so changing one limit that way would drop every other setting. To change a single setting, read the current policies, change that setting, and write them back with the revision you read.Change the setting
Find the usage policy, parse its value, and change only the setting you need.
This example raises the tenant’s CPU limit and leaves every other setting and policy as it was.
Write the policies back with the revision
FailedPrecondition error instead of overwriting their change. Read the policies again and repeat the change.Reading the policies again shows the new value and revision:Output
Expire a tenant
An expiration policy sets a date when the tenant expires, which suits trial tenants. Add it to the policy list next to the usage policy:expiresAt.
Usage policy settings
Next steps
Delete tenants
Remove a tenant when a customer leaves.
Resource limits
How limits apply to the compute a tenant runs.