You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sentinel publishes events to a message broker, which fans out messages to downstream adapters. It uses a **dual-trigger reconciliation strategy**:
64
+
Sentinel publishes events to a message broker, which fans out messages to downstream adapters. It uses a **three-part decision strategy**:
65
+
-**Never-processed**: Publish immediately for new resources that have never been processed
63
66
-**State-based**: Publish immediately when resource state indicates unprocessed spec changes
64
67
-**Time-based**: Publish periodically based on max age intervals to ensure eventual consistency
65
68
@@ -79,19 +82,36 @@ Deploy Sentinel when you need:
79
82
80
83
### 2.1 Decision Engine
81
84
82
-
Sentinel's decision engine evaluates resources during each poll cycle to determine when to publish events. It uses a **dual-trigger strategy** that combines two complementary mechanisms to ensure both immediate response to changes and eventual consistency over time:
85
+
Sentinel's decision engine evaluates resources during each poll cycle to determine when to publish events. It uses a **three-part decision strategy** that ensures both immediate response to changes and eventual consistency over time:
83
86
84
-
1.**State-Based Reconciliation** — Immediate event publishing when resource state indicates unprocessed spec changes, which is checked first
85
-
2.**Time-Based Reconciliation** — Periodic event publishing to handle drift and failures when state is in sync
87
+
1.**Never-Processed Reconciliation** — Immediate event publishing for new resources that have never been processed by any adapter
88
+
2.**State-Based Reconciliation** — Immediate event publishing when resource state indicates unprocessed spec changes
89
+
3.**Time-Based Reconciliation** — Periodic event publishing to handle drift and failures when state is in sync
86
90
87
91
**How Sentinel Reads Resource State:**
88
92
89
-
When Sentinel polls the HyperFleet API, it retrieves cluster or nodepool resources with their current state.
93
+
When Sentinel polls the HyperFleet API, it retrieves cluster or nodepool resources with their current state.
90
94
91
95
1.**`resource.Generation`** — Retrieved from the API resource. The HyperFleet API increments this value every time the resource spec is updated.
92
96
2.**`resource.status`** — Extracted from the API resource's `type=Ready` condition.
93
97
94
-
#### 2.1.1 State-Based Reconciliation
98
+
#### 2.1.1 Never-Processed Reconciliation
99
+
100
+
Never-processed reconciliation is the **first and highest-priority check** that ensures new resources are published immediately on the first poll cycle after creation.
101
+
102
+
**How It Works:**
103
+
104
+
Sentinel checks if `status.LastUpdated` is zero (meaning no adapter has ever updated the resource status):
105
+
106
+
- If zero → **Publish immediately** with reason `"never processed"`
107
+
- If non-zero → Proceed to state-based check
108
+
109
+
**Why This Matters:**
110
+
111
+
- New clusters are published within one poll interval (~5s)
112
+
- Ensures consistent handling of all new resources regardless of generation initialization
113
+
114
+
#### 2.1.2 State-Based Reconciliation
95
115
96
116
State-based reconciliation is a **spec-change detection mechanism** where Sentinel immediately publishes events when resource state indicates the spec has changed but hasn't been fully processed yet.
97
117
@@ -105,35 +125,14 @@ Sentinel detects unprocessed spec changes by comparing the resource's `generatio
105
125
106
126
**Note**: Sentinel uses the Ready condition's `ObservedGeneration` field as a proxy signal for spec changes. While the Ready condition can also be False for other reasons (e.g., adapter-reported infrastructure failures), the `ObservedGeneration` field specifically tracks spec processing, making this an effective spec-change detection mechanism.
Sentinel->>Broker: CloudEvent (reason: state change detected)
124
-
Broker->>Adapter: Consume event
125
-
Adapter->>API: Reconcile cluster
126
-
Adapter->>API: Update status (observed_generation: 2)
127
-
```
128
-
129
128
**Key Properties:**
130
129
131
130
-**Immediate Response**: No need to wait for max age interval when state indicates unprocessed changes
132
131
-**Idempotent**: Adapters can safely process the same generation multiple times
133
132
-**Race Prevention**: Ensures spec changes are never missed due to timing
134
133
-**Condition-Based**: Uses Ready condition data as a reliable proxy for tracking spec processing status
135
134
136
-
#### 2.1.2 Time-Based Reconciliation (Max Age Intervals)
135
+
#### 2.1.3 Time-Based Reconciliation (Max Age Intervals)
137
136
138
137
Time-based reconciliation ensures **eventual consistency** by publishing events periodically, even when specs haven't changed. This handles external state drift and transient failures.
139
138
@@ -148,42 +147,44 @@ Sentinel uses two configurable max age intervals based on the resource's status
148
147
149
148
**Decision Logic:**
150
149
151
-
When the resource's `generation` matches the `Ready` condition's `ObservedGeneration` (indicating the condition reflects the current state), Sentinel checks if enough time has elapsed:
150
+
At this point, we know `status.last_updated` is not zero, so we can use it as the reference timestamp:
152
151
153
-
1. Calculate reference timestamp:
154
-
- If `status.last_updated` exists → use it (adapter has processed resource)
155
-
- Otherwise → use `created_time` (new resource never processed)
156
-
157
-
2. Determine max age interval:
152
+
1. Determine max age interval based on ready status:
158
153
- If resource is ready (`Ready` condition status == True) → use `max_age_ready` (default: 30m)
159
154
- If resource is not ready (`Ready` condition status == False) → use `max_age_not_ready` (default: 10s)
160
155
161
-
3. Calculate next event time:
162
-
```text
163
-
next_event = reference_time + max_age_interval
164
-
```
156
+
2. Calculate next event time:
157
+
-`next_event = last_updated + max_age_interval`
165
158
166
-
4. Compare with current time:
159
+
3. Compare with current time:
167
160
- If `now >= next_event` → **Publish event** (reason: "max age exceeded")
168
161
- Otherwise → **Skip** (reason: "max age not exceeded")
169
162
170
-
**Flow Diagram:**
163
+
#### 2.1.4 Complete Decision Flow
164
+
165
+
The three reconciliation checks work together in priority order to determine when to publish events:
-**Never-processed takes absolute priority** - New resources always publish immediately
185
+
-**State changes override max age** - Spec changes don't wait for intervals
186
+
-**Max age is the fallback** - Ensures eventual consistency when nothing else triggers
187
+
187
188
### 2.2 Resource Filtering
188
189
189
190
Resource filtering enables **horizontal scaling** by allowing operators to distribute resources across multiple Sentinel instances using label-based selectors.
@@ -362,7 +363,7 @@ The `message_data` field defines the CloudEvents payload structure using **Commo
362
363
| Variable | Type | Description | Example Fields |
0 commit comments