From eb70700e4891980f5c713bb607a087423e12fff1 Mon Sep 17 00:00:00 2001 From: Simon Gerber Date: Thu, 17 Oct 2024 14:56:01 +0200 Subject: [PATCH] Fix typo in "triggering autmoated maintenance" decision --- .../ROOT/pages/explanations/decisions/maintenance-trigger.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/modules/ROOT/pages/explanations/decisions/maintenance-trigger.adoc b/docs/modules/ROOT/pages/explanations/decisions/maintenance-trigger.adoc index 7fd8a0a9..e7e1ff80 100644 --- a/docs/modules/ROOT/pages/explanations/decisions/maintenance-trigger.adoc +++ b/docs/modules/ROOT/pages/explanations/decisions/maintenance-trigger.adoc @@ -85,7 +85,7 @@ Instead of adjusting openshift-managed-upgrade-operator to support our requireme By running an active component in the cluster we can easily monitor the cluster's state and upgrade progress from the same tool which triggers the upgrade. If we implement the active component from scratch, we've got full control over the tool's development. -This allows quick turnaround for adding features and fixing bugs, and avoids the potentially high maintenance burden of pulling in upstream updates if we were to for openshift-managed-upgrade operator. +This allows quick turnaround for adding features and fixing bugs, and avoids the potentially high maintenance burden of pulling in upstream updates if we were to fork the openshift-managed-upgrade operator. Additionally, it's unlikely that we could upstream our changes to openshift-managed-upgrade-operator, as we probably have different requirements than the OpenShift Dedicated product. Since we already have sufficient experience in implementing Kubernetes controllers/operators, the additional effort for the initial implementation should be acceptable.