Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 6 additions & 18 deletions docs/draft/concepts/clusterobjectsets.md
Original file line number Diff line number Diff line change
Expand Up @@ -88,7 +88,7 @@ When transitioning from one revision to the next:
1. A new ClusterObjectSet is created with the next sequential revision number
2. Both old and new revisions remain `Active` during the transition
3. Objects transition ownership from the old revision to the new one
4. Once the new revision reports `Succeeded`, the old revision can be archived
4. Once the new revision has rolled out successfully, the old revision can be archived

### Archival

Expand Down Expand Up @@ -196,19 +196,7 @@ For a detailed design discussion, see [Large Bundle Support](large-bundle-suppor

## Status conditions

ClusterObjectSets report three conditions that describe their current state:

### Progressing

Indicates whether the revision is actively rolling out.

| Status | Reason | Meaning |
| --- | --- | --- |
| True | `RollingOut` | Actively making progress |
| True | `Retrying` | Encountered a retryable error |
| True | `Succeeded` | Reached the desired state |
| False | `Blocked` | Error requiring manual intervention |
| False | `Archived` | No longer actively reconciled |
ClusterObjectSets report a single `Ready` condition describing their current state. Rollout *completion* is recorded separately as a timestamp in `status.completedAt`, not as a condition.

### Ready

Expand All @@ -222,16 +210,16 @@ Indicates whether all objects in the revision have been successfully rolled out
| False | `ObjectCollision` | One or more objects are controlled by another owner, or are unowned and collision protection prevents adoption |
| False | `PreconditionsNotMet` | A precondition for applying the revision is not yet satisfied (a referenced Secret is mutable or has invalid or changed content, or a preflight dry-run was rejected, e.g. an immutable field, a conflicting object, or RBAC/dependency CRDs not yet propagated); the revision keeps retrying and recovers once the precondition is met |
| False | `InvalidSpecification` | The revision spec is invalid (a malformed revision/phase object or progression probe); requires a spec change |
| False | `ProgressDeadlineExceeded` | The revision did not roll out within `spec.progressDeadlineMinutes` |
| False | `Archiving` | The revision is being archived; owned objects are still being torn down |
| False | `Archived` | Objects torn down after archival |
| Unknown | `Pending` | The revision has not yet been evaluated (initial state) |
| Unknown | `Migrated` | Migrated from existing release; probes not yet observed |

On a revision's first reconciliation the `Ready` condition is initialized to `Unknown`/`Pending`, so it is always present. A transient internal error (e.g. an API read failure) leaves the `Ready` condition unchanged and is retried with backoff; it is not reported as a distinct reason (while the revision is still `Pending`, it stays `Unknown`/`Pending`).

### Succeeded
### Completion (`status.completedAt`)

A terminal condition set once the rollout completes. It persists even if the revision later becomes unavailable, marking that this version was successfully deployed at least once.
The first time a revision becomes ready, the controller stamps `status.completedAt` with the current time. This timestamp is set once and never changes, marking that this revision successfully rolled out at least once — it persists even if the revision later becomes not ready. The ClusterExtension controller uses it to determine the installed revision.

## How operator-controller uses ClusterObjectSets

Expand All @@ -254,7 +242,7 @@ When a ClusterExtension is upgraded to a new version:
1. A new ClusterObjectSet is created with `revision: N+1`
2. Both old and new revisions are `Active` during the transition
3. Objects transition ownership from the old revision to the new one
4. Once the new revision reports `Succeeded`, the old revision is archived
4. Once the new revision has rolled out successfully, the old revision is archived
5. Older archived revisions are garbage collected, keeping the last 5 for auditing

### Relationship with ClusterExtension
Expand Down
Loading