Fuzzball Documentation
Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Back to homepage
  1. Fuzzball Guides
  2. /
  3. Fuzzball Entity Management
  4. /
  5. Organization Management
  6. /
  7. Managing the Organization Compute Policy

Managing the Organization Compute Policy

An organization’s compute policy is the set of compute instance types that users in the organization are permitted to run workflows on. Every instance type surfaced by any provisioner in the deployment appears in a catalog; the organization owner selects a subset and saves it. Only selected instance types can be requested by workflows placed under the organization.

A single grant applies to every connected cluster that offers the named instance type; grants cannot be scoped to one cluster. On a single-cluster deployment this is a distinction without a difference. On a federated deployment, granting aws,m5.large allows the workflow to be placed on any federated cluster whose provisioner catalog exposes the m5.large SKU.

Grants are only enforced when computePolicy.enforce: true is set in central config. The default is false (the section is absent from the shipped fuzzball-common.yaml), which means grants are recorded but every workflow is allowed to run regardless of policy. Check your deployment’s fuzzball-common.yaml (or ask your cluster operator) before treating a grant as a security boundary.

Recommended order of operations for a new cluster:

  1. If desired, configure computePolicy.defaultDefinitions so new organizations arrive pre-seeded with a starter policy.
  2. Grant the intended instance types at the organization level.
  3. Submit a test workflow to confirm placement lands on a granted type.
  4. Flip computePolicy.enforce: true to make the policy a boundary.

On deployments that pre-configure computePolicy.defaultDefinitions in central config, new organizations are automatically seeded with those grants at creation time. Organization owners can add or revoke grants afterward.

If your deployment enabled defaultDefinitions after this organization was created, seeding happens automatically within about a minute of the config change. If you land on this page and the policy is empty on a deployment you expect to be pre-seeded, wait a minute and reload before raising a support ticket. See the central-config reference for the seeding and enforcement matrix.

Please select either the web UI or CLI tab to see the appropriate instructions for your environment.

Prerequisites

  • Organization owner permissions
  • At least one connected cluster with a provisioner catalog (a cluster with no provisioners will show an empty catalog)

Opening the Compute Page

  1. Log in to your Fuzzball UI as an organization owner.
  2. Under Manage Organization in the left navigation, click Compute.

The page opens on the current policy. If no grants have been made yet, the page shows the No compute grants empty state with a Manage compute grants button to add the first grant.

Browsing the Catalog

Each row in the catalog is one instance type surfaced by the deployment:

ColumnMeaning
KindThe provisioner backend (e.g., aws, gcp, oci, azure, coreweave, slurm, pbs, static)
Instance typeThe provisioner-defined instance type identifier
Cost / hourEstimated on-demand cost per hour, from the provisioner definition
GrantedWhether the type is included in the current organization policy

Use the Search field to filter by name and the Filters button to narrow by kind or by grant status.

Editing the Policy

  1. Toggle the Granted checkbox for each instance type you want to add or remove.
  2. Click Save changes in the upper right.

Changes take effect immediately for new workflow placements across every connected cluster. Workflows already running are not affected.

Removing a grant does not stop workflows that are already using that instance type. It only prevents new placements onto that type.

Prerequisites

  • Fuzzball CLI installed
  • Active CLI context for a user with organization owner permissions

Grant Syntax

Every command that adds or removes grants takes one or more grants on the command line. A grant has the form KIND,INSTANCE_TYPE, for example aws,m5.large or gcp,n2-standard-8. KIND matches the provisioner backend kind and INSTANCE_TYPE matches the backend SKU – the cloud provider’s own name for the machine type (m5.large, n2-standard-8, Standard_D2s_v3, etc.) – not the provisioner definition identifier. Renaming or grouping definitions in central config does not change the SKU a grant must name; a grant of aws,m5.large succeeds as long as some cluster in the organization still exposes a definition backed by the m5.large SKU.

To discover the SKUs a cluster exposes, look at the INSTANCE TYPE column of fuzzball organization compute-policy get, the compute catalog in the web UI, or the backendId field of fuzzball node provisioner list -o yaml. The Id column of fuzzball node provisioner list is the provisioner definition identifier – do not use it in a grant.

Viewing the Current Policy

$ fuzzball organization compute-policy get

Adding Grants

Add one or more instance types without touching existing grants:

$ fuzzball organization compute-policy add aws,r7a.xlarge
$ fuzzball organization compute-policy add aws,m5.large aws,m5.xlarge

add is additive. Adding a grant that already exists is a no-op.

Removing Grants

Remove one or more instance types without touching the rest:

$ fuzzball organization compute-policy remove aws,m5.large

Removing a grant that is not present is a no-op.

Replacing the Policy

Set the policy across all clusters to exactly the supplied grants. Clusters that offered any of the previously-granted types have those grants revoked:

$ fuzzball organization compute-policy set aws,m5.large aws,t3.medium

set requires at least one grant – it cannot express an empty policy. To clear the policy entirely, use remove for each remaining grant.

When to use which command: use add and remove for incremental edits; use set only when you intend to declare the full policy (for example, applying a policy from a config file or CI pipeline).

Empty organization policy under enforcement: an organization with zero grants denies all workflow placement when computePolicy.enforce: true (unlike an empty group policy, which inherits the organization’s grants). Keep at least one grant in place if you need any workflows to run.

Rejected Grants

The server rejects any grant that no connected cluster can satisfy. On a single cluster the error reads:

none of the submitted grants name an instance type available on this cluster

On a federated deployment the error names the specific (backend_kind, backend_id) pair that no cluster offers. This most commonly means a typo in the instance type name or a stale grant left over after a provisioner definition was removed from central config.

What Users See When a Placement Is Denied

When a workflow’s target instance type is not in the effective policy, the workflow fails placement. Users see it one of two ways:

  • Web UI: a Compute policy denied this workflow dialog lists the excluded provisioner definitions per cluster, so an end user can see exactly which grants are missing.
  • CLI: the submission fails with an error naming each cluster that evaluated the workflow, the provisioner definitions the organization policy excluded, and the provisioner definitions the group policy excluded. Cross-reference the excluded IDs with fuzzball node provisioner list (whose Id column matches) to identify the SKUs behind them and decide which grants are missing.

Delegating to Groups

Organization owners set the outer boundary; individual groups may subset that policy to further restrict what a group’s members can run. See Managing a Group Compute Policy.

gdoc_arrow_left_alt Listing Organization Members User Management gdoc_arrow_right_alt