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
Copy file name to clipboardExpand all lines: docs/content/docs/concepts/controller-flow.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -98,7 +98,7 @@ It’s very important to understand that the Observer phase records a point-in-t
98
98
The `AbstractFlinkResourceReconciler` encapsulates the core reconciliation flow for all Flink resource types. Let’s take a look at the high level flow before we go into specifics for session, application and session job resources.
99
99
100
100
1. Check if the resource is ready for reconciliation or if there are any pending operations that should not be interrupted (manual savepoints for example)
101
-
2. If this is the first deployment attempt for the resource, we simply deploy it. It’s important to note here that this is the only deploy operation where we use the `flinkStateSnapshotReference` provided in the spec.
101
+
2. If this is the first deployment attempt for the resource, we simply deploy it. It’s important to note here that this is the only deploy operation where we use the `initialSavepointPath` provided in the spec.
102
102
3. Next we determine if the desired spec changed and the type of change: `IGNORE, SCALE, UPGRADE`. Only for scale and upgrade type changes do we need to execute further reconciliation logic.
103
103
4. If we have upgrade/scale spec changes we execute the upgrade logic specific for the resource type
104
104
5. If we did not receive any spec change we still have to ensure that the currently deployed resources are fully reconciled:
Copy file name to clipboardExpand all lines: docs/content/docs/custom-resource/job-management.md
+4-5Lines changed: 4 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -247,17 +247,16 @@ Users have two options to restore a job from a target savepoint / checkpoint
247
247
248
248
### Redeploy using the savepointRedeployNonce
249
249
250
-
It is possible to redeploy a `FlinkDeployment` or `FlinkSessionJob` resource from a target savepoint by using the combination of `savepointRedeployNonce` and `flinkStateSnapshotReference` in the job spec:
250
+
It is possible to redeploy a `FlinkDeployment` or `FlinkSessionJob` resource from a target savepoint by using the combination of `savepointRedeployNonce` and `initialSavepointPath` in the job spec:
# If not set previously, set to 1, otherwise increment, e.g. 2
257
256
savepointRedeployNonce: 1
258
257
```
259
258
260
-
When changing the `savepointRedeployNonce` the operator will redeploy the job to the savepoint defined in the `flinkStateSnapshotReference`. The savepoint path must not be empty.
259
+
When changing the `savepointRedeployNonce` the operator will redeploy the job to the savepoint defined in the `initialSavepointPath`. The savepoint path must not be empty.
261
260
262
261
{{< hint warning >}}
263
262
Rollbacks are not supported after redeployments.
@@ -271,7 +270,7 @@ However, this also means that savepoint history is lost and the operator won't c
271
270
1. Locate the latest checkpoint/savepoint metafile in your configured checkpoint/savepoint directory.
272
271
2. Delete the `FlinkDeployment` resource for your application
273
272
3. Check that you have the current savepoint, and that your `FlinkDeployment` is deleted completely
274
-
4. Modify your `FlinkDeployment` JobSpec and set `flinkStateSnapshotReference.path` to your last checkpoint location
273
+
4. Modify your `FlinkDeployment` JobSpec and set `initialSavepointPath` to your last checkpoint location
275
274
5. Recreate the deployment
276
275
277
276
These steps ensure that the operator will start completely fresh from the user defined savepoint path and can hopefully fully recover.
@@ -188,11 +176,10 @@ This serves as a full reference for FlinkDeployment and FlinkSessionJob custom r
188
176
| state | org.apache.flink.kubernetes.operator.api.spec.JobState | Desired state for the job. |
189
177
| savepointTriggerNonce | java.lang.Long | Nonce used to manually trigger savepoint for the running job. In order to trigger a savepoint, change the number to a different non-null value. |
190
178
| initialSavepointPath | java.lang.String | Savepoint path used by the job the first time it is deployed or during savepoint redeployments (triggered by changing the savepointRedeployNonce). |
191
-
| flinkStateSnapshotReference | org.apache.flink.kubernetes.operator.api.spec.FlinkStateSnapshotReference | Snapshot reference used by the job the first time it is deployed or during savepoint redeployments (triggered by changing the savepointRedeployNonce). |
192
179
| checkpointTriggerNonce | java.lang.Long | Nonce used to manually trigger checkpoint for the running job. In order to trigger a checkpoint, change the number to a different non-null value. |
193
180
| upgradeMode | org.apache.flink.kubernetes.operator.api.spec.UpgradeMode | Upgrade mode of the Flink job. |
194
181
| allowNonRestoredState | java.lang.Boolean | Allow checkpoint state that cannot be mapped to any job vertex in tasks. |
195
-
| savepointRedeployNonce | java.lang.Long | Nonce used to trigger a full redeployment of the job from the savepoint path specified in initialSavepointPath or the path/FlinkStateSnapshot reference in flinkStateSnapshotReference. In order to trigger redeployment, change the number to a different non-null value. Rollback is not possible after redeployment. |
182
+
| savepointRedeployNonce | java.lang.Long | Nonce used to trigger a full redeployment of the job from the savepoint path specified in initialSavepointPath. In order to trigger redeployment, change the number to a different non-null value. Rollback is not possible after redeployment. |
Copy file name to clipboardExpand all lines: docs/content/docs/custom-resource/snapshots.md
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -38,7 +38,7 @@ If you set this to false, the operator will keep using the deprecated status fie
38
38
To create a savepoint or checkpoint, exactly one of the spec fields `savepoint` or `checkpoint` must present.
39
39
Furthermore, in case of a savepoint you can signal to the operator that the savepoint already exists using the `alreadyExists` field, and the operator will mark it as a successful snapshot in the next reconciliation phase.
40
40
41
-
You can also instruct the Operator to start a new FlinkDeployment/FlinkSessionJob from an existing snapshot CR by using `flinkStateSnapshotReference` in the job spec.
41
+
You can also instruct the Operator to start a new FlinkDeployment/FlinkSessionJob from an existing snapshot by using `initialSavepointPath` in the job spec.
42
42
43
43
## Examples
44
44
@@ -78,11 +78,11 @@ spec:
78
78
79
79
### Start job from existing snapshot
80
80
81
+
To start a job from an existing snapshot, you need to extract the path then use:
82
+
81
83
```yaml
82
84
job:
83
-
flinkStateSnapshotReference:
84
-
namespace: flink # not required if it's in the same namespace
85
-
name: example-savepoint
85
+
initialSavepointPath: [savepoint_path]
86
86
```
87
87
88
88
{{< hint warning >}}
@@ -131,7 +131,7 @@ This feature is not available for checkpoints.
131
131
## Triggering snapshots
132
132
133
133
Upgrade savepoints are triggered automatically by the system during the upgrade process as we have seen in the previous sections.
134
-
In this case, the savepoint path will also be recorded in the `upgradeSnapshotReference` job status field, which the operator will use when restarting the job.
134
+
In this case, the savepoint path will also be recorded in the `upgradeSavepointPath` job status field, which the operator will use when restarting the job.
135
135
136
136
For backup, job forking and other purposes savepoint and checkpoints can be triggered manually or periodically by the operator, however generally speaking these will not be used during upgrades and are not required for the correct operation.
Copy file name to clipboardExpand all lines: docs/content/docs/operations/upgrade.md
+3-4Lines changed: 3 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -148,20 +148,19 @@ Here is a reference example of upgrading a `basic-checkpoint-ha-example` deploym
148
148
```
149
149
5. Restore the job:
150
150
151
-
Deploy the previously deleted job using this [FlinkDeployemnt](https://raw.githubusercontent.com/apache/flink-kubernetes-operator/main/examples/basic-checkpoint-ha.yaml) with `v1beta1` and explicitly set the `job.flinkStateSnapshotReference.path` to the savepoint location obtained from the step 1.
151
+
Deploy the previously deleted job using this [FlinkDeployemnt](https://raw.githubusercontent.com/apache/flink-kubernetes-operator/main/examples/basic-checkpoint-ha.yaml) with `v1beta1` and explicitly set the `job.initialSavepointPath` to the savepoint location obtained from the step 1.
Copy file name to clipboardExpand all lines: flink-kubernetes-operator-api/src/main/java/org/apache/flink/kubernetes/operator/api/spec/FlinkStateSnapshotReference.java
Copy file name to clipboardExpand all lines: flink-kubernetes-operator-api/src/main/java/org/apache/flink/kubernetes/operator/api/spec/JobReference.java
+1-8Lines changed: 1 addition & 8 deletions
Original file line number
Diff line number
Diff line change
@@ -44,16 +44,9 @@ public class JobReference {
44
44
/** Name of the Flink resource. */
45
45
privateStringname;
46
46
47
-
/**
48
-
* Namespace of the Flink resource. If empty, the operator will use the namespace of the
0 commit comments