Order LLMInferenceServiceConfig last in ODH overlay for upgrade safety (#1427)

Move LLMInferenceServiceConfig resources to a thin wrapper component
listed last in the ODH overlay, ensuring they appear after controllers
and webhooks in FIFO sort order. This prevents upgrade failures (e.g.
3.3 -> 3.4) where the new llmisvc controller is deployed but the
ValidatingWebhookConfiguration still uses the old configuration,
blocking LLMInferenceServiceConfig resources from being applied.

Signed-off-by: Pierangelo Di Pilato <pierdipi@redhat.com>

Author: pierDipi

config/overlays/odh/kustomization.yaml

@@ -3,7 +3,6 @@ kind: Kustomization
 
 resources:
 - ../../base
-- ../../llmisvcconfig
 # - ../../crd/full/localmodel
 - rbac/
 - accelerators/
@@ -14,6 +13,18 @@ components:
 - ../../components/kserve
 - ../../components/llmisvc
 # - ../../localmodels
+# LLMInferenceServiceConfig resources listed last so they appear after all other
+# resources in FIFO sort order (components are appended after resources).
+# This ordering is critical for upgrades (e.g. 3.3 -> 3.4). In 3.3, there was
+# a single uber controller + webhook that included the llmisvc controller. In
+# 3.4, llmisvc has its own separate controller + webhook. During upgrades the
+# cluster is in a mixed state: the new controller(s) get deployed but the
+# ValidatingWebhookConfiguration may still use the old configuration, which is
+# incompatible with the new controller(s). If LLMInferenceServiceConfig
+# resources are applied before the webhook is fully updated, validation fails
+# and blocks the operator (DSC) from becoming ready. Placing these resources
+# last gives the controllers and webhooks a chance to be reconciled first.
+- llmisvcconfig/
 
 namespace: opendatahub
 

config/overlays/odh/llmisvcconfig/kustomization.yaml

@@ -0,0 +1,18 @@
+# Thin wrapper component to include LLMInferenceServiceConfig resources last
+# in the FIFO sort order. Components are appended after resources, so listing
+# this as the last component ensures LLMInferenceServiceConfig comes at the end.
+#
+# This ordering is critical for upgrades (e.g. 3.3 -> 3.4). In 3.3, there was
+# a single uber controller + webhook that included the llmisvc controller. In
+# 3.4, llmisvc has its own separate controller + webhook. During upgrades the
+# cluster is in a mixed state: the new controller(s) get deployed but the
+# ValidatingWebhookConfiguration may still use the old configuration, which is
+# incompatible with the new controller(s). If LLMInferenceServiceConfig
+# resources are applied before the webhook is fully updated, validation fails
+# and blocks the operator (DSC) from becoming ready. Placing these resources
+# last gives the controllers and webhooks a chance to be reconciled first.
+apiVersion: kustomize.config.k8s.io/v1alpha1
+kind: Component
+
+resources:
+  - ../../../llmisvcconfig