Managing a Group Compute Policy
Each group has its own compute policy that further restricts which instance types the group’s members can run workflows on. A group’s policy is bounded above by its organization’s policy: the group owner picks a subset of what the organization has already granted.
A new group with no grants is permissive: its members can place workflows on any instance type the organization grants. A group policy takes effect only once it holds at least one grant, at which point placement is restricted to the intersection of the organization’s grants and the group’s grants. Enforcement itself is gated bycomputePolicy.enforce: truein central config; see the organization compute policy page for the enforcement gate details.
A group’s policy must be a subset of the organization’s policy. A grant that names an instance type the organization has not granted is rejected – a group can only grant a subset of what its organization has already made available.
New groups start with an empty policy. The group owner picks which of the organization’s granted instance types to grant to this group’s members; nothing is granted to members until the first policy is saved.
If the organization owner later revokes a grant that a group still holds, two things happen:
- The grant is immediately excluded from workflow placement. A workflow is only allowed to place on an instance type that appears in both the organization’s and the group’s grants, and the org set no longer contains it.
- Within about a minute, the orphaned group grant is deleted. Until then,
fuzzball group compute-policy getmay still list the revoked grant.
If the organization owner later re-grants the same instance type, the group grant does not return automatically – the group owner must add it again.
The subset rule is enforced when a grant is saved and again when a workflow is placed. Fuzzball checks a workflow’s target instance type against both sets:
- The organization’s grants for the workflow owner’s organization
- The group’s grants for the workflow owner’s group
Placement is only allowed if the instance type appears in the intersection. Revoking a grant at the organization level immediately excludes that instance type from every group that had re-granted it, without touching the underlying group grant records.
Fuzzball does not union policy across a user’s groups at placement time. Each workflow is submitted under exactly one group – whichever group the workflow’s owning identity is bound to at submission time – and only that group’s grants are considered, intersected with the organization’s.
To switch which group a CLI submission runs under before submitting, use
fuzzball group use.
If a member needs to place a workload on an instance type their current group
does not grant, either add the grant to the current group or switch groups.
Because groups do not union at placement time, a user’s group taxonomy is a
policy-design decision, not just a permissions convenience. A few broad
groups keeps grants simple but couples unrelated members under the same
policy. Many narrow groups gives precise control but forces users to select
the right group with group use before every submission.
- Group owner permissions on the target group (organization owners have this transitively)
- At least one connected cluster with a provisioner catalog
- Log in to your Fuzzball UI as a group owner or organization owner.
- Under Manage Organization in the left navigation, click Groups.
- Select the target group.
- Open the Compute tab in the group detail view.
The catalog shows only instance types the organization has granted. Types the organization has not granted are not visible.
- Toggle the Granted checkbox for each instance type you want the group’s members to be able to use.
- Click Save changes in the upper right.
Changes take effect immediately for new workflow placements. Workflows already running are not affected.
- Fuzzball CLI installed
- Active CLI context for a user with group owner permissions on the target group
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. The second field is the backend
instance type (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.
To discover the SKUs a cluster exposes, look at the INSTANCE TYPE column
of fuzzball group 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.
Group commands accept an optional GROUP name or ID as the first positional
argument. When omitted, the command operates on the currently-selected group;
see fuzzball group use.
# Current group
$ fuzzball group compute-policy get
# A specific group
$ fuzzball group compute-policy get my-group# Current group
$ fuzzball group compute-policy add aws,r7a.xlarge
# A specific group
$ fuzzball group compute-policy add my-group aws,r7a.xlargeadd is additive. Adding a grant that already exists is a no-op.
$ fuzzball group compute-policy remove aws,m5.large
$ fuzzball group compute-policy remove my-group aws,m5.largeSet the group’s policy across all clusters to exactly the supplied grants:
$ fuzzball group compute-policy set aws,m5.large aws,t3.medium
$ fuzzball group compute-policy set my-group aws,m5.large aws,t3.medium
setrequires at least one positional argument. Supplying only aGROUPname (fuzzball group compute-policy set my-group) clears that group’s policy entirely, restoring the permissive inherit-from-org default. Supplying grants without aGROUP(fuzzball group compute-policy set aws,m5.large) replaces the current group’s policy with just those grants.When to use which command: use
addandremovefor incremental edits; usesetonly when you intend to declare the full policy (for example, applying a policy from a config file or CI pipeline).
The server rejects any grant that the organization has not granted, or 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 within the organization’s policy:
no cluster offers backend_kind="aws" backend_id="m5.large"
Ask the organization owner to grant the instance type at the organization level first, then retry the group operation.
- Managing the Organization Compute Policy – the outer set that constrains every group’s policy.
- What Users See When a Placement Is Denied – how a denied workflow reports which group grants excluded it.
computePolicy.enforce– cluster-wide enforcement flag.