From 50ffc02e9b4de2409b8e30f965c7d09770821f38 Mon Sep 17 00:00:00 2001 From: Joe Betz Date: Wed, 23 Jun 2021 10:30:58 -0700 Subject: [PATCH] Split documentation according to both mechanisms available for migration Kubernetes-commit: 7f893f6bd62357e52ee77ddc64dd163a4a5f1224 --- applyconfigurations/doc.go | 25 ++++++++++++++++--------- 1 file changed, 16 insertions(+), 9 deletions(-) diff --git a/applyconfigurations/doc.go b/applyconfigurations/doc.go index 72ef9d1c..48fdd660 100644 --- a/applyconfigurations/doc.go +++ b/applyconfigurations/doc.go @@ -14,7 +14,7 @@ See the License for the specific language governing permissions and limitations under the License. */ -// Code generated by client-gen. DO NOT EDIT. +// Code generated by applyconfiguration-gen. DO NOT EDIT. /* Package applyconfigurations provides typesafe go representations of the apply @@ -104,7 +104,10 @@ representation to be changed to support additional features in the future. Controller Support -The new client-go support makes it much easier to use Server-side Apply in controllers, by either of two mechanisms. +The new client-go support makes it much easier to use Server-side Apply in controllers, by either of +two mechanisms. + +Mechanism 1: When authoring new controllers to use Server-side Apply, a good approach is to have the controller recreate the apply configuration for an object each time it reconciles that object. This ensures @@ -115,13 +118,17 @@ reconciliation loop that apply is called from. When upgrading existing controllers to use Server-side Apply the same approach often works well--migrate the controllers to recreate the apply configuration each time it reconciles any -object. Unfortunately, the controller might have multiple code paths that update different parts of -an object depending on various conditions. Migrating a controller like this to Server-side Apply can -be risky because if the controller forgets to include any fields in an apply configuration that is -included in a previous apply request, a field can be accidentlly deleted. To ease this type of -migration, client-go apply support provides a way to replace any controller reconciliation code that -performs a "read/modify-in-place/update" (or patch) workflow with a "extract/modify-in-place/apply" -workflow. Here's an example of the new workflow: +object. For cases where this does not work well, see Mechanism 2. + +Mechanism 2: + +When upgrading existing controllers to use Server-side Apply, the controller might have multiple +code paths that update different parts of an object depending on various conditions. Migrating a +controller like this to Server-side Apply can be risky because if the controller forgets to include +any fields in an apply configuration that is included in a previous apply request, a field can be +accidentally deleted. For such cases, an alternative to mechanism 1 is to replace any controller +reconciliation code that performs a "read/modify-in-place/update" (or patch) workflow with a +"extract/modify-in-place/apply" workflow. Here's an example of the new workflow: fieldMgr := "my-field-manager" deploymentClient := clientset.AppsV1().Deployments("default")