c-pius
commented
8 months ago This issue can be reproduced via Busola. In a new cluster, Istio is enabled by default and when editing the KymaCR via Edit->YAML functionality, it is possible to add the same istio entry twice resulting in the following KymaCR:
Resulting KymaCR
```yaml apiVersion: operator.kyma-project.io/v1beta2 kind: Kyma metadata: annotations: operator.kyma-project.io/owned-by: kcp-system/c316bc8d-2110-497e-86b1-8bcb568ee580 creationTimestamp: "2024-01-22T15:45:52Z" generation: 2 labels: operator.kyma-project.io/watched-by: lifecycle-manager name: default namespace: kyma-system resourceVersion: "14036" uid: 9ace2b53-1cd2-467a-a84a-c8a746f8b802 spec: channel: fast modules: - customResourcePolicy: CreateAndDelete name: api-gateway - customResourcePolicy: CreateAndDelete name: istio - customResourcePolicy: CreateAndDelete name: istio status: activeChannel: fast conditions: - lastTransitionTime: "2024-01-22T15:53:25Z" message: all modules are in ready state observedGeneration: 1 reason: Ready status: "True" type: Modules - lastTransitionTime: "2024-01-22T15:53:25Z" message: module templates are synchronized observedGeneration: 1 reason: Ready status: "True" type: ModuleCatalog - lastTransitionTime: "2024-01-22T15:53:25Z" message: skrwebhook is synchronized observedGeneration: 1 reason: Ready status: "True" type: SKRWebhook lastOperation: lastUpdateTime: "2024-01-22T15:53:25Z" operation: kyma is ready modules: - channel: fast fqdn: kyma-project.io/module/istio manifest: apiVersion: operator.kyma-project.io/v1beta2 kind: Manifest metadata: generation: 1 name: c316bc8d-2110-497e-86b1-8bcb568ee580-istio-4034478325 namespace: kcp-system name: istio resource: apiVersion: operator.kyma-project.io/v1alpha2 kind: Istio metadata: name: default namespace: kyma-system state: Ready template: apiVersion: operator.kyma-project.io/v1beta2 kind: ModuleTemplate metadata: generation: 2 name: istio-fast namespace: kcp-system version: 1.2.1 - channel: fast fqdn: kyma-project.io/module/api-gateway manifest: apiVersion: operator.kyma-project.io/v1beta2 kind: Manifest metadata: generation: 1 name: c316bc8d-2110-497e-86b1-8bcb568ee580-api-gateway-1209152227 namespace: kcp-system name: api-gateway resource: apiVersion: operator.kyma-project.io/v1alpha1 kind: APIGateway metadata: name: default namespace: "" state: Ready template: apiVersion: operator.kyma-project.io/v1beta2 kind: ModuleTemplate metadata: generation: 3 name: api-gateway-fast namespace: kcp-system version: 2.1.0 state: Ready ```The same cannot be achieved when editing KymaCR via kubectl apply, kubectl edit, or kyma alpha enable module (see also tests on local k3d cluster below).
The PR that updated the enforcement of unique values is here https://github.com/kyma-project/lifecycle-manager/pull/611. This seems to work as expected for kubectl and kyma cli, but Busola's Edit-YAML functionality somehow seems to bypass it.
A Kyma installation where this issue is reproduced is in cs-test-1242 Subaccount under our Stage Global Account.
Tests on local k3d cluster
Given the following KymaCR:
apiVersion: operator.kyma-project.io/v1beta2
kind: Kyma
metadata:
annotations:
operator.kyma-project.io/owned-by: kcp-system/kyma-sample
labels:
operator.kyma-project.io/watched-by: lifecycle-manager
name: default
namespace: kyma-system
spec:
channel: regular
modules:
- channel: regular
customResourcePolicy: CreateAndDelete
name: template-operatorkyma alpha enable module template-operatorwill yield a successfulmodules patchedmessage, the KymaCR remains unchanged howeverkubectl edit ...fails with:# kymas.operator.kyma-project.io "default" was not valid: # * spec.modules[1]: Duplicate value: map[string]interface {}{"name":"template-operator"}kubectl apply ...fails withThe Kyma "default" is invalid: spec.modules[1]: Duplicate value: map[string]interface {}{"name":"template-operator"}- also tried with
--validate='ignore'and--server-sideflags which result in the same behavior
- also tried with
Further Observations
- first failure log for this issue in CLS is at
2024-01-11T13:02:10.445535918Z. The logs from 30 mins before this error didn't show any significant hints - module names are not normalized (trim whitespace, lowercase, etc.)
- e.g., adding modules like
name: ' template-operator'orname: Template-operatorworks - however, reconcile loop will fail with
no such module founderror
- e.g., adding modules like
- :exclamation: alternative ways of naming the module works, e.g
name: template-operatorandname: kyma-project.io/module/template-operator- KymaCR does list the module twice, each under the provided name
- reconcile loop worked for the
template-operatorcase Status.Moduleslists the module twice- see also details below
janmedrek
Description
It has been observed that the user was able to configure duplicated entry in the
.spec.moduleslist in an SKR cluster. The LM couldn't handle this condition nicely - the proper error was only visible in the LM logs, not in the Kyma status or an Event on the Kyma object. The Kyma CRD schema should prevent this from happenning, but apparently something went wrong.Steps to reproduce
To be found, start with trying to add the same module twice.
Environment Type
Managed
Environment Info
Shoot name:
https://api.c-5a489c4.stage.kyma.ondemand.comKubernetes Version:Server Version: version.Info{Major:"1", Minor:"27", GitVersion:"v1.27.6", GitCommit:"741c8db18a52787d734cbe4795f0b4ad860906d6", GitTreeState:"clean", BuildDate:"2023-09-13T09:14:09Z", GoVersion:"go1.20.8", Compiler:"gc", Platform:"linux/amd64"}Attachments
kyma-with-duplicated-module.txt kyma-with-duplicated-module.error.log.txt