Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test".
(Note: "add to whitelist" is no longer supported. Please update configurations in kubernetes/test-infra/jenkins/job-configs/kubernetes-jenkins-pull instead.)

This message may repeat a few times in short succession due to jenkinsci/ghprb-plugin#292. Sorry.

Otherwise, if this message is too spammy, please complain to ixdy.

Rather than allowing DNS names or env var names, can we just loosen the regex to [-A-Za-z0-9.]*[A-Za-z0-9][-A-Za-z0-9.]* or something equally loose? @pmorie? This will affect "automatic" secret file projections, but these are all valid filenames....

That probably makes sense... we would also need to allow underscores...

@thockin I have pushed something based on the suggestion, its a little more complex than you suggested as there are some tests checking that we don't allow keys with double dots through. I am not sure why that would be an issue though...

Is there a reason that you need the keys to be in a different format? We are adding control over the path and filename within the secret volume, and you have to specify an env var name if you consume a secret as an env var.

See #25285

In #23722 the usecase was that it is harder to build tooling that is targeting environment variables if everything has to have two names.

Clearly it is possible to work around this by encoding the names somehow. But I don't know of a good reason why the keys should be limited this much?

I just think it would be a good thing to make the interface simple to folks building tooling on bash and such. At the moment in my tool the we are hex encoding keys where they are env var names, but that has the downside that they get longer and are totally unreadable by someone using kubectl or whatnot.

I merely found it annoying an without actual benefit that I couldn't use the same names as env vars. Specifically I was taking a doc that someone had written about what env vars their app needed and putting it in a config map and I had to double-name everything. foo-bar-bat and FOO_BAR_BAT. Blech. Is there a reason? I can't think of one.

What is the progress of this? I cherry-pick the PR and test, underscore still not a valid key for ConfigMap.

Thanks for trying this @liyimeng, I will take a look at this later today...

Thanks @errm! Here is how I test:

[liyi@K8s-builder ~]$ kubectl create configmap ssh-config --from-file /etc/kolla/nova-ssh/id_rsa.pub
error: id_rsa.pub is not a valid key name for a configMap

sorry @errm, that was a fault alarm. Totally my fault, I forget to update kubectl in my test node. The validation is actually also done in kubectl.

@liyimeng It won't be in for 1.3.

I would really prefer to see a proposal for changing the key format, since I think it will be a little more complicated than 'allow underscores'.

@pmorie I can create a proposal for this... It just seemed like such a small change.

I do see the point of view that once we loosen some validation we can never tighten it up again, so I guess it should be something to have a wider discussion about...

Is there some documentation on how to write a proposal properly somewhere?

Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test".
(Note: "add to whitelist" is no longer supported. Please update configurations in kubernetes/test-infra/jenkins/job-configs/kubernetes-jenkins-pull instead.)

This message may repeat a few times in short succession due to jenkinsci/ghprb-plugin#292. Sorry.

Otherwise, if this message is too spammy, please complain to ixdy.

I'm trying to create a configmap for a Caddyfile (https://caddyserver.com/) and getting burned by the fact that the standard container images expect the name "Caddyfile". Config files starting with a capital letter seems somewhat common (I can think of Gemfile and Cargo.toml off the top of my head).

Is there any reason this supports dns names and env vars rather than linux file names, as @thockin mentioned?

@cgag It does support file names . . . just not keys in the configMap that are non dns. When you add the map to a container you are able to map to file names.

@thockin is there any way I can help to move this forward?

@errm, Woops, you're right, I see now that I can mount the keys to custom paths, thanks. I'd gotten used to just using the keys as the filenames.

Still, it'd be nice to not have to do that, so it'd be cool to see this go forward.

Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test".
(Note: "add to whitelist" is no longer supported. Please update configurations in kubernetes/test-infra/jenkins/job-configs/kubernetes-jenkins-pull instead.)

This message may repeat a few times in short succession due to jenkinsci/ghprb-plugin#292. Sorry.

Otherwise, if this message is too spammy, please complain to ixdy.

@thokin nits squashed . . .

@thockin @errm

I have to say, I still don't understand what value this provides -- you have to specify the name of the key in the environment specification anyway.

For simple auto-expansion into file projections, I can now express a much
wider array of file names without needing to write out the individual
projections.

Next, expect someone to suggest a streamlined form of env vars that don't
require you to spell the name twice. Just watch.

On Mon, Aug 1, 2016 at 2:38 PM, Paul Morie notifications@github.com wrote:

@thockin https://github.com/thockin @errm https://github.com/errm

I have to say, I still don't understand what value this provides -- you
have to specify the name of the key in the environment specification
anyway.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#25458 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVMnyuZu_3HPoXoU576pkqm1ucfiSks5qbmdNgaJpZM4IbwmI
.

Yes ultimately I would like to be able to say project all the keys from this configMap and/or secret to environment variables.

In my usecase:
We already build a map or secret per project & environment that contains the env vars we need.

Then we need to loop over each key and build a valid config for the env section.

This at the moment involves looking at each variable we want, then mapping it's name to something valid.

At the moment if we start with an environment variable name, say FOO_BAR we then need to translate it to something like foo-bar. This is fine if we are doing this by hand (if a little bit of a pain). But if I wan't to do this automatically we can't really make a nice translation, because what happens if someone decides they want the environment variable foo-bar to be set as well. The solution we are using now is to pack the keys as hex, so the keys in our secrets look like 464f4f5f424152. This works fine, but breaks looking at things in kubectl (and being able to reed them), and just makes the whole process a little more complex and hard to use/understand.

Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test".
(Note: "add to whitelist" is no longer supported. Please update configurations in kubernetes/test-infra/jenkins/job-configs/kubernetes-jenkins-pull instead.)

This message may repeat a few times in short succession due to jenkinsci/ghprb-plugin#292. Sorry.

Otherwise, if this message is too spammy, please complain to ixdy.

@thockin

Next, expect someone to suggest a streamlined form of env vars that don't require you to spell the name twice. Just watch.

I'm expecting it -- already thinking about how I want the API to look :)

@errm LGTM. Sorry for the latency on this, I've been out a lot recently and have been seriously underwater / bankrupt on github notifications.

GCE e2e build/test passed for commit d4969ff.

• Test Results
• Build Log
• Test Artifacts
• Internal Jenkins Results

Thanks for the patch!

@k8s-bot test this [submit-queue is verifying that this PR is safe to merge]

@k8s-bot e2e test this issue #29966

GCE e2e build/test passed for commit d4969ff.

• Test Results
• Build Log
• Test Artifacts
• Internal Jenkins Results

Automatic merge from submit-queue

GCE e2e build/test passed for commit d4969ff.

• Test Results
• Build Log
• Test Artifacts
• Internal Jenkins Results

@pmorie could you please promote this patch into the v1.3.6 release?

This doesn't meet the bar for a patch release to 1.3, I think

On Aug 12, 2016 6:57 AM, "kayrus" notifications@github.com wrote:

@pmorie https://github.com/pmorie could you please promote this patch
into the v1.3.6 release?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#25458 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVE0TM15SZS3ov9F8W8o5H76X4_NGks5qfHvDgaJpZM4IbwmI
.

Agreed, while this certainly shouldn't break anything currently using secrets or configMap, it is certainly a change to API and should wait for the next minor version.