Change the clusters on which the admins of the organization will be able to create projects. The new set must be a (non-strict) subset of the allowedClusters set of the parent organization.

This operation overwrites the currently allowed set of clusters, so make sure to include any clusters you want to keep in the request.

When projects exist

If there are projects in the organization that are not on the new allowed clusters, the operation will fail.

Example: Assume an organization org with allowed cluster [westeurope-1], and one project proj on that cluster. If the caller tries to remove westeurope-1 from the allowed clusters, the operation will fail, since proj is on a cluster that would not be allowed anymore.

Cascading removals

When removing a cluster from an organization, it will also be removed from all descendant organizations. This cascading behavior does not apply when adding a cluster.

Example: Assume an organization hierarchy like: org-a -> org-b -> org-c. The initially allowed clusters are:

• org-a: [westeurope-1, asia-northeast1-1]
• org-b: [westeurope-1, asia-northeast1-1]
• org-c: [westeurope-1]

Assume a caller changes the allowed clusters for org-a to [asia-northeast1-1]. The new allowed clusters will be:

• org-a: [asia-northeast1-1]
• org-b: [asia-northeast1-1]
• org-c: []

Access control

Requires the caller to be an admin in any of the organization's ancestors.

Example: Assume an organization hierarchy like: org-a -> org-b -> org-c. To change the allowed clusters for org-c, which means calling 'PUT /orgs/org-c/allowedClusters', the caller must be an admin in org-a, or org-b. Being an admin in org-c does not grant access.