Certain config elements become json when going to the application deployment page

[davidkarlsen]

Description:

Certain config values become json in the upgrade page of an app.

Steps to reproduce the issue:

1. Go to applications and select an application, scroll down the the "installation values" section and observe that all values are yaml
2. Click upgrade, observe that the section of install values now is a mix of yaml and json as outlined below

Describe the results you received:

env: [ { name: TZ, value: Europe/Oslo } ]

finods:
  {
    application: aml-cmt-api,
    applicationEnvironment: p1,
    group: eos,
    systemShortname: aml
  }

Describe the results you expected:

env:
- name: TZ
  value: Europe/Oslo
finods:
  application: aml-cmt-api
  applicationEnvironment: p1
  group: eos
  systemShortname: aml

Additional information you deem important (e.g. issue happens only occasionally):

Version of Helm, Kubeapps and Kubernetes:

• Output of helm version:

helm: N/A - kubeapps runs helm

• Output of helm list <kubeapps-release-name>:

kubeapps-helm3  kubeapps-helm3  2               2020-05-29 11:42:07.153037457 +0000 UTC deployed        kubeapps-3.6.0  v1.10.0    

• Output of kubectl version:

kubectl version
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.3", GitCommit:"2e7996e3e2712684bc73f0dec0200d64eec7fe40", GitTreeState:"clean", BuildDate:"2020-05-21T14:51:23Z", GoVersion:"go1.14.3", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.5+icp-ee", GitCommit:"eb4df6c6fb47f5b4fd1ed8bfbfe2d0ed5ea636e1", GitTreeState:"clean", BuildDate:"2019-05-08T02:18:32Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"}

[davidkarlsen]

Releated: #1683

[absoludity]

Isn't the output received a valid YAML representation though? I thought he previous issue was where the key was incorrectly parsed as json (so changing the structure), where as the example above is valid, but not ideal (ie. it's much more readable when using indentation to denote scope, rather than explicit braces). Let's see what Andres thinks when he's back.

[andresmgot]

hi, yes, as @absoludity points out, the issue in #1683 is different since the resulting YAML was syntactically incorrect. In this case both YAMLs represents the same object but it's true that it can be confusing.

The cause of this is the JSON diff that gets automatically generated between the default values and the deployed values. Let's say that we have this original YAML:

env: []

And the deployed version looks like this:

env:
- name: TZ
  value: Europe/Oslo

This gets detected as if the first element of the array env (/env/0) has now the value {name: "TZ", value: "Europe/Oslo"} so it gets converted into JSON when printing it as a string. See the example I reproduced with the NodeJS console:

> aDoc = yaml.parseDocument("env: []")
Document {
...
}
> aDoc.setIn(["env", 0], {name: "TZ", value: "Europe/Oslo"})
undefined
> console.log(aDoc.toString())
env: [ { name: TZ, value: Europe/Oslo } ]

It's different when the value of env is empty for example since it gets detected as a whole new element:

> aDoc = yaml.parseDocument("env:")
Document {
...
}
> aDoc.setIn(["env"], [{name: "TZ", value: "Europe/Oslo"}])
undefined
> console.log(aDoc.toString())
env:
  - name: TZ
    value: Europe/Oslo

so, in other words, can you post the original values of env and finods @davidkarlsen? (the ones in the original values.yaml). That way we can try to mitigate this issue refactoring how elements are added.

[absoludity]

Closing, please re-open if there's more info as requested.