From 2ac804b442061c51f072b9eb7cb5ade70fb85e23 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Attila=20M=C3=A9sz=C3=A1ros?= Date: Mon, 2 Dec 2024 15:10:33 +0100 Subject: [PATCH 1/2] docs: add external state tracking into FAQ MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Attila Mészáros --- docs/content/en/docs/faq/_index.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/docs/content/en/docs/faq/_index.md b/docs/content/en/docs/faq/_index.md index 79264332ef..09cae6e8eb 100644 --- a/docs/content/en/docs/faq/_index.md +++ b/docs/content/en/docs/faq/_index.md @@ -74,6 +74,24 @@ is `true` (`false` by default). To disable, set it to `false` at [Operator-level Operator operator = new Operator( override -> override.checkingCRDAndValidateLocalModel(false)); ``` +### Q: I'm managing an external resource that has a generated ID, where should I store that? + +It is common that a non-Kubernetes or external resource is managed from a controller. Those external resources might +have a generated ID, so are not simply addressable based on the spec of a custom resources. Therefore, the +generated ID needs to be stored somewhere in order to address the resource during the subsequent reconciliations. + +Usually there are two options you can consider to store the ID: + +1. Create a separate resource (usually ConfigMap, Secret or dedicated CustomResource) where you store the ID. +2. Store the ID in the status of the custom resource. + +Note that both approaches are a bit tricky, since you have to guarantee the resources are cached for the next +reconciliation. For example if you patch the status at the end of the reconciliation (`UpdateControl.patchStatus(...)`) +it is not guaranteed that during the next reconciliation you will see the fresh resource. Therefore, controllers +which do this, usually cache the updated status in memory to make sure it is present for next reconciliation. + +Dependent Resources supports explicitly the [first approach](../dependent-resources/_index.md#external-state-tracking-dependent-resources). + ### Q: How to fix `sun.security.provider.certpath.SunCertPathBuilderException` on Rancher Desktop and k3d/k3s Kubernetes It's a common issue when using k3d and the fabric8 client tries to connect to the cluster an exception is thrown: From de582693b13df937fbe9dc15ddf88136c4e0e660 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Attila=20M=C3=A9sz=C3=A1ros?= Date: Mon, 2 Dec 2024 15:12:44 +0100 Subject: [PATCH 2/2] wip MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Attila Mészáros --- docs/content/en/docs/faq/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/content/en/docs/faq/_index.md b/docs/content/en/docs/faq/_index.md index 09cae6e8eb..4fb35dd2b9 100644 --- a/docs/content/en/docs/faq/_index.md +++ b/docs/content/en/docs/faq/_index.md @@ -90,7 +90,7 @@ reconciliation. For example if you patch the status at the end of the reconcilia it is not guaranteed that during the next reconciliation you will see the fresh resource. Therefore, controllers which do this, usually cache the updated status in memory to make sure it is present for next reconciliation. -Dependent Resources supports explicitly the [first approach](../dependent-resources/_index.md#external-state-tracking-dependent-resources). +Dependent Resources feature supports the [first approach](../dependent-resources/_index.md#external-state-tracking-dependent-resources). ### Q: How to fix `sun.security.provider.certpath.SunCertPathBuilderException` on Rancher Desktop and k3d/k3s Kubernetes