Skip to content
This repository has been archived by the owner on Sep 9, 2020. It is now read-only.

MySql generates incorrect yaml for ConfigMap #67

Open
ScottGuymer opened this issue May 23, 2018 · 1 comment
Open

MySql generates incorrect yaml for ConfigMap #67

ScottGuymer opened this issue May 23, 2018 · 1 comment

Comments

@ScottGuymer
Copy link

I ran into a problem when trying to sue the MySql template

When it generates the ConfigMap it seems to add in a key under the data property called configurationFiles:

You can see the line here int he generated example
https://github.com/ksonnet/parts/blob/master/incubator/mysql/examples/generated.yaml#L4

When you try to apply this example to a cluster

apiVersion: v1
data: 
  configurationFiles: 
    mysql.cnf: |
        - [mysqld]
        skip-name-resolve
kind: ConfigMap
metadata: 
  name: mysql
  namespace: default

you get the following response

error: error validating "test.yaml": error validating data: ValidationError(ConfigMap.data.configurationFiles): invalid type for io.k8s.api.core.v1.ConfigMap.data: got "map", expected "string"; if you choose to ignore these errors, turn validation off with --validate=false

But when you remove the line containing configurationFiles: it applies sucessfully

@ScottGuymer
Copy link
Author

I found a workaround was to pass in my own config files to the function that creates the configmap.

local configFiles = {
        "mysql.cnf":
         |||
         - [mysqld]
         skip-name-resolve
        |||,
    };

mysql.parts.configMap(namespace, name, configFiles)

It seems to be the default value for that parameter is the issue.

currently the function looks like this

configMap(namespace,name,configurationFiles=
      {configurationFiles: {
        "mysql.cnf":
         |||
         - [mysqld]
         skip-name-resolve
        |||,
    }}):: {
        apiVersion: "v1",
        kind: "ConfigMap",
        metadata: {
          name: name,
          namespace: namespace,
        },
        data: configurationFiles,
      },

I think we just need to remove the configurationFiles property from the default value.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant