dot character in environment variable name yields "invalid value"

[mike-hogan]

I modified the pod json from here https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/getting-started-guides/aws-coreos.md to have this in it:

  "containers": [{
    "name": "hello",
    "env": [
            {
              "name": 'oms.port',
              "value": 9000,
            }],
    "image": "quay.io/kelseyhightower/hello",
    "ports": [{
      "containerPort": 80,
      "hostPort": 80
    }]
  }]

and when I do kubecfg -c pod.json create pods, I get

F1202 08:48:01.907263 04825 kubecfg.go:403] Got request error: pod "hello" is invalid: desiredState.manifest.containers[0].env[0].name: invalid value 'oms.port'

I am using Kubernetes 0.5.4

[erictune]

The following doesn't work in bash:

$ oms.port=9000
-bash: oms.port=9000: command not found

so it doesn't work in kubernetes either.

[erictune]

Please feel free to reopen if I've misunderstood.

[wstrange]

The issue (which is still present in Kube 1.5.3) is that a dot is not allowed in the podspec for
environment variables names.

Some systems (elasticsearch for example) use dotted env var names. Example:

 - name: transport.host
      value: 127.0.0.1

The above fails with

Deployment.extensions "es-es-kibana" is invalid: spec.template.spec.containers[0].env[2].name: Invalid value: "transport.host": must match the regex [A-Za-z_][A-Za-z0-9_]*

[keegancsmith]

@erictune Funnily enough this hit us as well today for elasticsearch. Docker had this restriction and reverted it since POSIX pretty clearly states that you should tolerate env strings you don't understand. See more in the relevant docker issue moby/moby#16585

[timoreimann]

With the explanation from here quoted on the referenced Docker issue, it seems to me that Kubernetes is similar to Docker in the sense that it's just an intermediary that should always pass environment variables through to the application even when they contain "illegal characters"; the reason being that applications may not be subject to the same restrictions as bash.

@erictune Do you think this is worth creating a new issue or reopening this one?

[yongzhang]

+1
We have the same issue to start elasticsearch with Kubernetes.

[AlmogBaku]

Since docker have changed it, and large-scaled applications such as ElasticSearch requires it, I guess it worth reconsideration.

/reopen

[k8s-ci-robot]

@AlmogBaku: you can't re-open an issue unless you authored it or you are assigned to it.

In response to this:

Since docker have changed it, and large-scaled applications such as ElasticSearch requires it, I guess it worth reconsideration.

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[k8s-github-robot]

@mike-hogan There are no sig labels on this issue. Please add a sig label by:
(1) mentioning a sig: @kubernetes/sig-<team-name>-misc
(2) specifying the label manually: /sig <label>

Note: method (1) will trigger a notification to the team. You can find the team list here.

[timoreimann]

I'd like to take a stab at relaxing Kubernetes' validation logic so that dotted environment variables are allowed.

If there's anything I should do or any design work that's needed up front prior to shooting out a PR, please let me know.

[0xmichalis]

@kubernetes/sig-node-proposals

[mtaufen]

It sounds reasonable to me. I'll throw one point out there though: relaxing validation can be tricky because you never know who's come to rely on existing validation - e.g. does anyone rely on Kubernetes preventing dotted env var names? I personally don't think this should stop us from making this specific change, but opinions may differ from mine.

@timoreimann I would just make a PR and see what people think.

[timoreimann]

thanks @mtaufen -- will follow up with a PR and see what folks have to say.

[martinmosegaard]

A workaround for Elasticsearch until this is fixed is to use command arguments in your Kubernetes deployment spec like so:

spec:
  containers:
  - image: docker.elastic.co/elasticsearch/elasticsearch:5.4.2
    ...
    command: ["bin/elasticsearch"]
    args: ["-Ehttp.host=0.0.0.0", "-Etransport.host=127.0.0.1"]

As documented under configuration here:
https://www.elastic.co/guide/en/elasticsearch/reference/current/docker.html

[timoreimann]

Super quick update: I've started work on this. Should hopefully be able to submit a PR soonish.

[dliappis]

@martinmosegaard Is correct in that currently a workaround to configuring the Elasticsearch Docker image on Kubernetes (on top of bind mounting a config file or using a customized image) is by overriding CMD, i.e. option D in the Elasticsearch Docker documentation.

[timoreimann]

My PR just got merged. Once released, environment variable names with dots (and dashes) should generally be supported.

[webwurst]

I see that the fix got merged at Aug 8, but when trying Kubernetes v1.7.7, released on Sep 29 the following error still shows up for me:

The Deployment "elasticsearch" is invalid: spec.template.spec.containers[0].env[1].name: Invalid value: "bootstrap.memory_lock": a valid C identifier must start with alphabetic character or '_', followed by a string of alphanumeric characters or '_' (e.g. 'my_name',  or 'MY_NAME',  or 'MyName', regex used for validation is '[A-Za-z_][A-Za-z0-9_]*')

In which Kubernetes version is this issue supposed to be fixed?

[timoreimann]

@webwurst it'll only be available in 1.8.

[johnculviner]

If you are stuck on <1.8 for the time being this fixed it all for me with elasticsearch (the similar answer above didn't quite cut it) hope this helps someone

      - image: docker.elastic.co/elasticsearch/elasticsearch:6.2.2
...
        command: ["/usr/local/bin/docker-entrypoint.sh"]
        args: ["bin/elasticsearch", "-Ediscovery.type=single-node"]

[ObviousDWest]

I just got burned trying to put override values from an application.properties file for a spring boot application into a configMap (in a deployment). It appears to have dotted keys stripped out before they are added as environment variables in the container (without any error/warning message). I don't know if the issue is with "env", "envFrom" or somewhere else. But given how prevalent spring boot is, and how it is designed to pick up settings from environment variables, it would be super useful if the could be passed through from a config map.
Running 1.14.

[ObviousDWest]

Sorry to necro this thread. My issue turned out to be because I used "sh" in the command, which strips dotted names. Switching to "bash" allowed the variables to pass through as expected.