Requesting quota changes

Before you start

• You know your current tier — run kubectl describe resourcepool to check (see Seeing your allocation).
• You understand the tier numbers and the shared pool model.

The four tiers

Every tenant is provisioned at one of four tiers. The full numbers are on the Resource pools and quotas page:

Tier	CPU limits	Memory limits	Storage requests
sandbox	2	4Gi	10Gi
standard	8	16Gi	50Gi
premium	32	64Gi	200Gi
custom	negotiated	negotiated	negotiated

Tier progression

The typical path is:

1. Sandbox → Standard — the common move once a research team has proven their workload runs and wants to move from experiments to a scheduled pipeline. Low friction, fast turnaround.
2. Standard → Premium — requires more justification because it reserves a non-trivial slice of the cluster. Include the workload profile (CPU/memory/storage footprint) in your ticket.
3. Any tier → Custom — negotiated per-project. Give RCS the approximate CPU, memory, and storage footprint you need and they will pick a pool shape that covers it.

What to include in the ticket

Open a ticket with RCS naming:

• Your tenant name (the Cloud RAP group name, e.g. def-profname or crg-profname-xx).
• Current tier (sandbox, standard, premium, or custom).
• Requested tier (or, for custom, the approximate CPU / memory / storage footprint).
• One-line rationale — for example: “workload now runs nightly and needs 16Gi of memory for the training step” or “adding a second pipeline that doubles our CPU needs.”
• Timeline — if the change is time-sensitive (e.g. a conference deadline), mention it.

The more specific the rationale, the faster the turnaround. “We need more resources” is harder to act on than “our batch job needs 24 CPU cores and 48Gi memory for 4 hours nightly.”

SLO expectations

• Sandbox → Standard: same day to next business day.
• Standard → Premium: 1–2 business days — RCS reviews the request against cluster capacity.
• Custom: 2–5 business days — RCS negotiates the pool shape with you and may need to coordinate with Alliance allocation if the request exceeds the backing Cloud RAP’s footprint.

These are typical turnaround times, not guarantees. Complex requests or requests during high-demand periods may take longer.

When to consider a RAC Cloud RAP instead

Tier changes adjust your quota within the same Cloud RAP. But the upstream allocation that backs your tenant is the Cloud RAP itself — if you are hitting the ceiling on a def-profname default RAP and your workload has grown into production, the durable fix may be applying to the annual Alliance Resource Allocation Competition (RAC) for a crg-profname-xx Cloud RAP with a larger footprint.

Signs that a RAC application is the right move:

• You are already at premium and still need more.
• Your workload is long-running and will need sustained capacity for a year or more.
• You need custom resources that exceed what a default Cloud RAP can back.

The RAC competition runs annually — check ccdb.alliancecan.ca for the current cycle’s deadlines. RCS can advise on whether a tier change, a new Cloud RAP, or a custom allocation is the right move for your workload.

What happens after a tier change

RCS updates the Capsule ResourcePool backing your tenant. The change takes effect immediately — no restart or re-login required. Your existing workloads continue running, and new workloads can use the updated quota limits right away.

Verify the change by running:

kubectl describe resourcepool

The Spec section shows the new tier’s CPU, memory, and storage limits. See Seeing your allocation for how to read the output.