From 7d3d40ae8368a33783958648881dbbf5047ca16b Mon Sep 17 00:00:00 2001 From: Carlos Salas Date: Tue, 7 May 2024 16:59:19 +0200 Subject: [PATCH] docs: edit hosted providers upstream/config sync (#1258) * docs: edit hosted providers specification sync Signed-off-by: Carlos Salas * docs: 2.7 edit hosted providers specification sync Signed-off-by: Carlos Salas * docs: 2.8 edit hosted providers specification sync Signed-off-by: Carlos Salas * Apply suggestions from code review --------- Signed-off-by: Carlos Salas Co-authored-by: Marty Hernandez Avedon --- .../rancher-server-configuration/sync-clusters.md | 4 ++++ .../rancher-server-configuration/sync-clusters.md | 4 ++++ .../rancher-server-configuration/sync-clusters.md | 4 ++++ 3 files changed, 12 insertions(+) diff --git a/docs/reference-guides/cluster-configuration/rancher-server-configuration/sync-clusters.md b/docs/reference-guides/cluster-configuration/rancher-server-configuration/sync-clusters.md index 53e7a4c6d9c..8ee65f0c248 100644 --- a/docs/reference-guides/cluster-configuration/rancher-server-configuration/sync-clusters.md +++ b/docs/reference-guides/cluster-configuration/rancher-server-configuration/sync-clusters.md @@ -40,6 +40,10 @@ The AKSConfig, EKSConfig or GKEConfig represents the desired state. Nil values a UpstreamSpec represents the cluster as it is in the hosted Kubernetes provider. It's refreshed every 5 minutes. After the UpstreamSpec is refreshed, Rancher checks if the cluster has an update in progress. If it's currently updating, nothing further is done. If it is not currently updating, any managed fields on AKSConfig, EKSConfig or GKEConfig are overwritten with their corresponding value from the recently updated UpstreamSpec. +:::warning +When you import a cluster from a cloud provider into Rancher, UpstreamSpec represents the cluster state and Config is empty. If you then update the imported cluster through the Rancher UI, both UpstreamSpec and Config become non-null. Any further updates to the cluster should be applied through Rancher. This is because there is no safe way to determine if changes originating from UpstreamSpec represent the desired state or just a mismatch with Config. If you update the imported cluster through the cloud provider console after you apply any updates through the Rancher UI, the controller will deploy a rollback and the content of Config will be considered the desired state. +::: + The effective desired state can be thought of as the UpstreamSpec, plus all non-nil fields in the AKSConfig, EKSConfig or GKEConfig. This is what is displayed in the UI. If Rancher and another source attempt to update a cluster at the same time, or within 5 minutes of an update finishing, any managed fields are likely to get caught in a race condition. To use EKS as an example, a cluster may have PrivateAccess as a managed field. If PrivateAccess is false and then enabled in EKS console at 11:01, and tags are updated from Rancher before 11:05, then the value is likely to be overwritten. This can also occur if tags are updated while the cluster is still processing the update. The issue described in this example shouldn't occur if the cluster is registered and the PrivateAccess fields are nil. diff --git a/versioned_docs/version-2.7/reference-guides/cluster-configuration/rancher-server-configuration/sync-clusters.md b/versioned_docs/version-2.7/reference-guides/cluster-configuration/rancher-server-configuration/sync-clusters.md index 53e7a4c6d9c..8ee65f0c248 100644 --- a/versioned_docs/version-2.7/reference-guides/cluster-configuration/rancher-server-configuration/sync-clusters.md +++ b/versioned_docs/version-2.7/reference-guides/cluster-configuration/rancher-server-configuration/sync-clusters.md @@ -40,6 +40,10 @@ The AKSConfig, EKSConfig or GKEConfig represents the desired state. Nil values a UpstreamSpec represents the cluster as it is in the hosted Kubernetes provider. It's refreshed every 5 minutes. After the UpstreamSpec is refreshed, Rancher checks if the cluster has an update in progress. If it's currently updating, nothing further is done. If it is not currently updating, any managed fields on AKSConfig, EKSConfig or GKEConfig are overwritten with their corresponding value from the recently updated UpstreamSpec. +:::warning +When you import a cluster from a cloud provider into Rancher, UpstreamSpec represents the cluster state and Config is empty. If you then update the imported cluster through the Rancher UI, both UpstreamSpec and Config become non-null. Any further updates to the cluster should be applied through Rancher. This is because there is no safe way to determine if changes originating from UpstreamSpec represent the desired state or just a mismatch with Config. If you update the imported cluster through the cloud provider console after you apply any updates through the Rancher UI, the controller will deploy a rollback and the content of Config will be considered the desired state. +::: + The effective desired state can be thought of as the UpstreamSpec, plus all non-nil fields in the AKSConfig, EKSConfig or GKEConfig. This is what is displayed in the UI. If Rancher and another source attempt to update a cluster at the same time, or within 5 minutes of an update finishing, any managed fields are likely to get caught in a race condition. To use EKS as an example, a cluster may have PrivateAccess as a managed field. If PrivateAccess is false and then enabled in EKS console at 11:01, and tags are updated from Rancher before 11:05, then the value is likely to be overwritten. This can also occur if tags are updated while the cluster is still processing the update. The issue described in this example shouldn't occur if the cluster is registered and the PrivateAccess fields are nil. diff --git a/versioned_docs/version-2.8/reference-guides/cluster-configuration/rancher-server-configuration/sync-clusters.md b/versioned_docs/version-2.8/reference-guides/cluster-configuration/rancher-server-configuration/sync-clusters.md index 53e7a4c6d9c..8ee65f0c248 100644 --- a/versioned_docs/version-2.8/reference-guides/cluster-configuration/rancher-server-configuration/sync-clusters.md +++ b/versioned_docs/version-2.8/reference-guides/cluster-configuration/rancher-server-configuration/sync-clusters.md @@ -40,6 +40,10 @@ The AKSConfig, EKSConfig or GKEConfig represents the desired state. Nil values a UpstreamSpec represents the cluster as it is in the hosted Kubernetes provider. It's refreshed every 5 minutes. After the UpstreamSpec is refreshed, Rancher checks if the cluster has an update in progress. If it's currently updating, nothing further is done. If it is not currently updating, any managed fields on AKSConfig, EKSConfig or GKEConfig are overwritten with their corresponding value from the recently updated UpstreamSpec. +:::warning +When you import a cluster from a cloud provider into Rancher, UpstreamSpec represents the cluster state and Config is empty. If you then update the imported cluster through the Rancher UI, both UpstreamSpec and Config become non-null. Any further updates to the cluster should be applied through Rancher. This is because there is no safe way to determine if changes originating from UpstreamSpec represent the desired state or just a mismatch with Config. If you update the imported cluster through the cloud provider console after you apply any updates through the Rancher UI, the controller will deploy a rollback and the content of Config will be considered the desired state. +::: + The effective desired state can be thought of as the UpstreamSpec, plus all non-nil fields in the AKSConfig, EKSConfig or GKEConfig. This is what is displayed in the UI. If Rancher and another source attempt to update a cluster at the same time, or within 5 minutes of an update finishing, any managed fields are likely to get caught in a race condition. To use EKS as an example, a cluster may have PrivateAccess as a managed field. If PrivateAccess is false and then enabled in EKS console at 11:01, and tags are updated from Rancher before 11:05, then the value is likely to be overwritten. This can also occur if tags are updated while the cluster is still processing the update. The issue described in this example shouldn't occur if the cluster is registered and the PrivateAccess fields are nil.