Vars-in-images would not work well with Image Reviews API. Not necessarily
a blocker.
Also, if we did decide to upstream OpenShift templates, we would need some
way to distinguish vars to be resolved at server-side
template-expansion-time vs kubelet-time.
On Sun, Oct 2, 2016 at 8:59 PM, 'Tim Ho
>
> - we think a good practice is to check config into revision control and
> then have a process that continuously kubectl-applies that checked in
> config to the cluster. You want to expand the templates before commiting
> to revision control, so that revision controlled config is repeatable, a
What about supporting env-expansion in the image name field? This
would allow things like populating ARCH from downward API, then using
`me/mycontainer-$(ARCH):v3.1.4` as image.
On Thu, Sep 29, 2016 at 9:12 AM, 'Eric Tune' via Kubernetes user
discussion and Q&A wrote:
> Short answer:
>
> There a
Thanks Eric, this was useful. We are exploring jsonnet and other templating
languages. You mentioned people are working on it, is there a issue/feature
where this is being tracked ?
-Mayank
On Thursday, September 29, 2016 at 9:12:36 AM UTC-7, Eric Tune wrote:
>
> Short answer:
>
> There are no
Short answer:
There are no kubectl features for this.
I would do:
cat foo.yaml.tpl | sed s/IMAGENAME/actualimagename | kubectl apply -f -
Long answer:
- we know there is a need for a reference system for templatized and
generated config for Kubernetes, and people are working on it, but we don
