Aggregator for ConfigMap resource implementation

[pmorie]

This issue aggregates the PRs for the implementation of the config resource described in #6477

• Proposal Config Resource Proposal #6477
• API Resource Generic Config object and its REST implementation #6245
• Kubectl tooling and associated tests kubectl support for ConfigMap #18712
• Environment variables and associated E2E tests Config resource in env vars #18974
• Move to main API Move ConfigMap to main API #19716
• API resource integration tests ConfigMap integration test #19792
• Make namespace controller delete ConfigMaps Make namespace controller delete configMaps in namespace #20645
• Volume Source and associated E2E tests ConfigMap Volume #20114
  • Generalize atomic projections into volumes Generalize atomically updating projections into volumes #20397
• Add kubectl create command Add kubectl create configmap command #20777
• Documentation ConfigMap docs #19782
• Quota for ConfigMap Add resource quota for ConfigMap #22183

cc @tmrts

[tmrts]

We'll need usage docs as well. A lot of people are anxious to try it out.

[therc]

The issue numbers for "Move to main API" and "Documentation" are the same; is that intended? I wanted to point out that https://github.com/kubernetes/kubernetes/blob/master/docs/design/configmap.md still talks about [valueFrom: configMap: configMapName:], while it should be [valueFrom: configMapKeyRef: name:]. It's not clear where to report that, though.

[thockin]

@pmorie

On Wed, Jan 27, 2016 at 8:23 AM, Rudi C notifications@github.com wrote:

The issue numbers for "Move to main API" and "Documentation" are the same;
is that intended? I wanted to point out that
https://github.com/kubernetes/kubernetes/blob/master/docs/design/configmap.md
still talks about [valueFrom: configMap: configMapName:], while it should
be [valueFrom: configMapKeyRef: name:]. It's not clear where to report
that, though.

—
Reply to this email directly or view it on GitHub
#18455 (comment)
.

[pmorie]

@therc updated, thanks for noticing that!

[therc]

Is there any plan to allow consuming ConfigMap items as e.g. command line flags? Even in #18215 I don't see any mentions of CM (the conversation is hard to follow...). And the downward API only sets environment variables. All I want to do is set e.g. the cluster name or some other cluster-wide constant once, then have a bunch of specs reflect that ("--domain=CLUSTER.example.com"). I'm not even talking about conditionals, regular expressions, arbitrary math leading to computing Mandelbrot sets, etc.: just straight text substitutions as a starting point.

[thockin]

You can already do env-var expansion in commandlines, so you should be able
to define an env var from a ConfigMap, then reference that env var in your
commandline as $(NAME)

On Fri, Jan 29, 2016 at 5:07 PM, Rudi C notifications@github.com wrote:

Is there any plan to allow consuming ConfigMap items as e.g. command line
flags? Even in #18215
#18215 I don't see any
mentions of CM (the conversation is hard to follow...). And the downward
API only sets environment variables. All I want to do is set e.g. the
cluster name or some other cluster-wide constant once, then have a bunch of
specs reflect that ("--domain=CLUSTER.example.com"). I'm not even talking
about conditionals, regular expressions, arbitrary math leading to
computing Mandelbrot sets, etc.: just straight text substitutions as a
starting point.

—
Reply to this email directly or view it on GitHub
#18455 (comment)
.

[pmorie]

You can already do env-var expansion in commandlines, so you should be able to define an env var from a ConfigMap, then reference that env var in your commandline as $(NAME)

bingo

[mwielgus]

cc: @piosz @fgrzadkowski

[davidopp]

@pmorie Please be sure to explain this prominently in the documentation (a lot of people will have the same question @therc had, since that's almost certainly going to be the main way that people consume ConfigMap).

[davidopp]

@pmorie All of the check boxes are checked now :) Should we close the issue?

[yvespp]

When I do "kubectl get" I don't see configmap in the error message, shouldn't it be there?

lodur:config yves$ kubectl version
Client Version: version.Info{Major:"1", Minor:"2+", GitVersion:"v1.2.0-alpha.8", GitCommit:"5918967a86489460846af94a5c393d971337be29", GitTreeState:"clean"}
Server Version: version.Info{Major:"1", Minor:"2+", GitVersion:"v1.2.0-alpha.8", GitCommit:"5918967a86489460846af94a5c393d971337be29", GitTreeState:"clean"}
lodur:config yves$ kubectl get 

You must specify the type of resource to get. Valid resource types include:
   * componentstatuses (aka 'cs')
   * events (aka 'ev')
   * endpoints (aka 'ep')
   * horizontalpodautoscalers (aka 'hpa')
   * ingress (aka 'ing')
   * jobs
   * limitranges (aka 'limits')
   * nodes (aka 'no')
   * namespaces (aka 'ns')
   * pods (aka 'po')
   * persistentvolumes (aka 'pv')
   * persistentvolumeclaims (aka 'pvc')
   * quota
   * resourcequotas (aka 'quota')
   * replicasets (aka 'rs')
   * replicationcontrollers (aka 'rc')
   * secrets
   * serviceaccounts
   * services (aka 'svc')
error: Required resource not specified.

[pmorie]

@yvespp that's weird -- i'll look into it.

@davidopp if you don't mind i'd like to keep it open to track any follow-up tasks that shake out over the next day or two.

[bgrant0607]

@pmorie Can this be closed? Is there an issue for docs?

[bgrant0607]

I see a PR for docs. Closing.