configmaps were GA in 1.2, right? So should this be marked as release-note-action-needed since it's a behavioral change to a GA API?

I think it is a release note, but not action required. It will change the behavior but not in any way that most users will really notice.

But @pmorie why? ConfigMap objects are already limited by API object size (1 MB today, unlikely to grow beyond O(tens) of MB). Does that memory cost and disk accounting matter? tmpfs has some really nice properties wrt performance...

The memory consumed is charged to the Kubelet and not the pod cgroup. If
you put a few hundred pods on the node each using multiple config maps, it
can add up. The argument for secrets is stronger than config maps. Not
doing this makes node accounting harder.

On Sunday, May 8, 2016, Kubernetes Bot notifications@github.com wrote:

GCE e2e build/test passed for commit e82195d
e82195d
.

• Build Log
  http://pr-test.k8s.io/25306/kubernetes-pull-build-test-e2e-gce/38936/build-log.txt
• Test Artifacts
  https://console.developers.google.com/storage/browser/kubernetes-jenkins/pr-logs/pull/25306/kubernetes-pull-build-test-e2e-gce/38936/artifacts/
• Internal Jenkins Results
  http://goto.google.com/prkubekins/job/kubernetes-pull-build-test-e2e-gce//38936

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#25306 (comment)

Ahh, of course. We know how to fix that, but we have to get a patch into
kernel. I forgot that this is a Google-specific behavior :(.

Can we leave a TODO here saying it probably should be tmpfs, but it needs
to be charged to the user container, when that becomes possible.
On May 8, 2016 5:11 AM, "Derek Carr" notifications@github.com wrote:

The memory consumed is charged to the Kubelet and not the pod cgroup. If
you put a few hundred pods on the node each using multiple config maps, it
can add up. The argument for secrets is stronger than config maps. Not
doing this makes node accounting harder.

On Sunday, May 8, 2016, Kubernetes Bot notifications@github.com wrote:

GCE e2e build/test passed for commit e82195d
<
e82195d

.

• Build Log
  <
  http://pr-test.k8s.io/25306/kubernetes-pull-build-test-e2e-gce/38936/build-log.txt
• Test Artifacts
  <
  https://console.developers.google.com/storage/browser/kubernetes-jenkins/pr-logs/pull/25306/kubernetes-pull-build-test-e2e-gce/38936/artifacts/
• Internal Jenkins Results
  <
  http://goto.google.com/prkubekins/job/kubernetes-pull-build-test-e2e-gce//38936

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
<
#25306 (comment)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#25306 (comment)

@thockin Should config maps be stored in tmpfs at all? Why do you think config maps demand high performance storage?

Thanks for the fix @pmorie !

We do work on the behalf of users. Once we get disk io limiting, we will
run into the old priority inversion problem, mitigated largely by
goroutine-per-pod.

But I argue tmpfs not for perf but for deterministic behavior.
On May 9, 2016 11:52 AM, "Vish Kannan" notifications@github.com wrote:

@thockin https://github.com/thockin Should config maps be stored in
tmpfs at all? Why do you think config maps demand high performance storage?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#25306 (comment)

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

GCE e2e build/test passed for commit 3567b1f.

• Build Log
• Test Artifacts
• Internal Jenkins Results

Automatic merge from submit-queue