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/en/blog/news/nonssa-vs-ssa.md
+2-2
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
---
2
2
title: From client side to server-side apply
3
-
date: 2025-02-17
3
+
date: 2025-02-25
4
4
---
5
5
6
6
From version 5 of Java Operator SDK [server side apply](https://kubernetes.io/docs/reference/using-api/server-side-apply/)
@@ -81,7 +81,7 @@ a custom resource is created using legacy approach is getting managed by new app
81
81
We prepared an integration test to demonstrate how such migration even in a simple case can go wrong,
82
82
and how to fix it.
83
83
84
-
Note that fixing might that you need to [strip managed fields](https://kubernetes.io/docs/reference/using-api/server-side-apply/#clearing-managedfields)
84
+
To fix some cases, you might need to [strip managed fields](https://kubernetes.io/docs/reference/using-api/server-side-apply/#clearing-managedfields)
85
85
from the custom resource.
86
86
87
87
See [`StatusPatchSSAMigrationIT`](https://github.com/operator-framework/java-operator-sdk/blob/main/operator-framework/src/test/java/io/javaoperatorsdk/operator/baseapi/statuspatchnonlocking/StatusPatchSSAMigrationIT.java) for details.
0 commit comments