Skip to content

An Instance is "Available" when it's ready to serve, even when scaled to zero#150

Merged
scotwells merged 1 commit into
mainfrom
split/api-rename
Jun 5, 2026
Merged

An Instance is "Available" when it's ready to serve, even when scaled to zero#150
scotwells merged 1 commit into
mainfrom
split/api-rename

Conversation

@scotwells

@scotwells scotwells commented Jun 5, 2026

Copy link
Copy Markdown
Contributor

Why Available, not Running

We're renaming the Instance readiness condition from Running to Available — and the reason is the user's mental model, not a cosmetic preference.

Running implies a process is actively executing right now. That's the wrong guarantee for a scale-to-zero Instance that's woken on activity: such an Instance may be scaled to zero with nothing executing, yet it is still fully available — it will accept a request and wake on demand. Reporting that Instance as not-Running would be alarming and simply wrong; reporting it as Available states the guarantee users actually care about — the workload is ready to serve — independent of whether anything is running at this instant.

So Available decouples readiness from runtime state. A dormant, scale-to-zero Instance and a warm, actively-serving one are both Available; the distinction between "asleep" and "executing" belongs in reasons/metrics, not in the top-level readiness signal. It also matches how the rest of the platform expresses "ready to use," keeping the signal consistent across resources.

What

  • The Instance readiness condition becomes Available instead of Running (the existing controller is updated to match, so nothing breaks today).
  • Status gets more informative: an Instance that isn't ready can now say why — still provisioning, image couldn't be pulled, the app is crashing, or the config was rejected — and Workloads/WorkloadDeployments surface rollout progress.
  • The published CRDs are regenerated to match.

This is an API-and-contract change only — no new controller behavior — and it builds and passes tests against main on its own.

⚠️ Breaking

The Instance Running condition is renamed to Available. Anything reading the Running condition (its type or reasons) must move to Available.

Stack

Base of the federation foundation: main ← this ← #107 ← …. Extracted from #107 so the breaking rename — and the rationale above — reviews on its own.

🤖 Generated with Claude Code

…d add federation status surface

BREAKING CHANGE: the Instance "Running" condition is renamed to "Available".
The InstanceRunning/InstanceReadyReasonRunning/InstanceRunningReason* constants
are removed in favor of InstanceAvailable/InstanceReadyReasonAvailable/
InstanceAvailableReason* (Stopped/Starting/Stopping/Available).

This extracts the shared API surface that the federation controllers
(#107 and the refdata stack) build on, so it can land independently as the
base of that stack:

- Renames the Instance condition from "Running" to "Available" across the
  Instance/Workload/WorkloadDeployment types and the generated CRDs.
- Adds the blocking-reason Ready constants used to surface why an Instance is
  not yet Available: InstanceReadyReasonImageUnavailable, InstanceCrashing,
  ConfigurationError, and Provisioning.
- Adds the additive rollout status fields UpdatedReplicas and
  ObservedGeneration consumed by the federation deployment controllers.
- Regenerates the CRDs under config/base/crd to match.
- Migrates the existing instance controller and its test to the renamed
  constants (rename only; no federation logic is introduced here).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@scotwells scotwells changed the title refactor(api)!: rename Instance "Running" condition to "Available" + federation status surface refactor(api)!: rename Instance "Running" condition to "Available" Jun 5, 2026
@scotwells scotwells changed the title refactor(api)!: rename Instance "Running" condition to "Available" An Instance is "Available" when it's ready to serve, even when scaled to zero Jun 5, 2026
@scotwells scotwells requested review from a team and savme June 5, 2026 18:48
@scotwells scotwells merged commit c8d5c1c into main Jun 5, 2026
9 checks passed
@scotwells scotwells deleted the split/api-rename branch June 5, 2026 19:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants