Change:
if !reflect.DeepEqual(pip.Spec.Env, pod.Spec.Containers[0].Env) { framework.Failf("env of pod container does not match the env of the pip: expected %#v, got: %#v", pip.Spec.Env, pod.Spec.Containers[0].Env) } <ins> if !reflect.DeepEqual(pip.Spec.Env, pod.Spec.InitContainers[0].Env) { framework.Failf("env of pod init container does not match the env of the pip: expected %#v, got: %#v", pip.Spec.Env, pod.Spec.InitContainers[0].Env) } </ins> }) It("should not modify the pod on conflict", func() {

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /sig cluster-lifecyle What happened: I created a Pod Preset to inject an environment variable. The Pod container gets properly injected, but the init container does not. A small sample is here: What you expected to happen: The init container would get the pod preset injected How to reproduce it (as minimally and precisely as possible): Run kubectl create -f on the following gist: Reproduced here: Anything else we need to know?: Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.3", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-11-09T07:26:38Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"darwin/amd64"} Server Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.0", GitCommit:"", GitTreeState:"dirty", BuildDate:"2017-10-17T15:09:55Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: minikube 0.23.0 OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: Started with:
/sig cluster-lifecyle /sig service-catalog
My use case: I have an a git init container that checkout out configuration. This needs to run before the main container (hence why it is an init container). I'd like to be able to simply annotate the pod with a label and have various environment variables (GIT_REPO, etc) supplied to the init container
Update from Slack discussion: Supporting Init containers is in the Beta proposal for PodPreset. PodPreset resource is going to be moved from core to service-catalog. We have an implementation based on Initializers, but looks like Initializers are not going to Beta soon and we might have to reimplement them using Webhooks.
Issues go stale after 90d of inactivity. Mark the issue as fresh with .

Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten /remove-lifecycle stale
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
It'd be nice if this worked, I suspect it would help the folks over at Knative Build implement support for passing HTTP_PROXY env vars and CA cert secrets to build steps.
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
We have a customer interested in seeing this fixed - if we submit a PR, are there objections to merging it?
cc
This is also affecting me - I have an init container that loads data from AWS Secrets and stores them in a volume that is accessed by the main container. The init container needs credentials that are passed via a podpreset
any ETA when support for initcontainers will be provided by PodPreset ?
This was fixed in 1.14.