PodPreset: Add same functionality for init containers as standard containers

[soggiest]

What type of PR is this?
/kind feature

What this PR does / why we need it:
Adds the same functionality for init containers as standard containers in the PodPreset admission controller.

Which issue(s) this PR fixes:
Fixes #55410

Does this PR introduce a user-facing change?:

Adds the same information to an init container as a standard container in a pod when using PodPresets.

[k8s-ci-robot]

Hi @soggiest. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[dims]

/ok-to-test

[ncdc]

@soggiest I would recommend updating test/e2e/servicecatalog/podpreset.go to include verifying the init containers were modified as expected.

[soggiest]

/retest

[soggiest]

/sig service-catalog

[soggiest]

/test all

[ncdc]

FWIW, since the PodPreset e2es don't seem to run in CI that I can find, I built a kube-apiserver with the changes from this PR, finagled it into a Minikube environment, and I was able to manually run the PodPreset e2e tests (including removing the skip that it should only run on gce), and everything passed.

[oomichi]

just one comment

[soggiest]

/retest

[oomichi]

Sorry for missing this point on my previous review.
After reading the original issue(#55410) carefully, the reporter wanted to set the init container specific environment values on podPresets.
Current ones are the same as the container's one of line 218. So it is better to set different environment value as the e2e test to verify the behavior.

[soggiest]

I don't see where the original user wanted there to be different values for the init container vs the main container. The way that I've read it is that they want podpresets to function with init containers at all.

[soggiest]

@kubernetes/sig-service-catalog-feature-requests
Can someone review this PR, please?

[mbarthelemy-grab]

Hi,
Will this get merged? Would be super useful for us (we need to be able to access PodPreset env vars from initContainers).

[ncdc]

@jessfraz @dims @smarterclayton @timothysc @pmorie - anyone object to this going in?

[derekwaynecarr]

@ncdc I thought we had decided against further evolution of pod preset in favor of webhooks out of tree, but it’s possible I missed something that changed.

[dims]

/milestone v1.14
/sig node
/assign @derekwaynecarr @deads2k

Let's mark this as v1.14 so folks look at it and we can yank it out if it does not make it (as @derekwaynecarr mentions that a decision was made at some point)

[smarterclayton]

We really should move forward with pod preset as a beta CRD and webhook in a kubernetes sig namespace. It’s a great feature, one that I think a lot of people want, and we’ve come so close. But according to the last state of this discussion, we did agree to move this out before we do much more work on it.

[ncdc]

@derekwaynecarr @smarterclayton @pmorie I completely understand the motivation for moving this out of tree. I agree with it. However, the current in-tree feature only applies the presets to normal containers, and not init containers. It's only doing half the job it should be doing. I'm advocating that we complete the in-tree feature with this PR. Is that ok for now, and going forward, someone can look at externalizing this?

[ncdc]

@smarterclayton @derekwaynecarr @pmorie bump

[soggiest]

@smarterclayton @derekwaynecarr @pmorie with code freeze coming up can we get another look at this PR, please?

[dims]

@ncdc i can buy that argument! so

/lgtm

[ncdc]

@dims thank you thank you thank you!

[ncdc]

/approve
(for the test bit)

[dims]

need the approvers though! @ncdc :)

[smarterclayton]

/approve

…

On Thu, Feb 28, 2019 at 3:15 PM Kubernetes Prow Robot < ***@***.***> wrote: [APPROVALNOTIFIER] This PR is *NOT APPROVED* This pull-request has been approved by: *ncdc <#71479 (comment)>*, *soggiest <#71479#>* To fully approve this pull request, please assign additional approvers. We suggest the following additional approver: *deads2k* If they are not already assigned, you can assign the PR to them by writing /assign @deads2k in a comment when ready. The full list of commands accepted by this bot can be found here <https://go.k8s.io/bot-commands?repo=kubernetes%2Fkubernetes>. The pull request process is described here <https://git.k8s.io/community/contributors/guide/owners.md#the-code-review-process> Needs approval from an approver in each of these files: - *plugin/pkg/admission/OWNERS <https://github.com/kubernetes/kubernetes/blob/master/plugin/pkg/admission/OWNERS>* - test/OWNERS <https://github.com/kubernetes/kubernetes/blob/master/test/OWNERS> [ncdc] Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#71479 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABG_p_YEIk4Ckb_VhvK8qKc8-WmLS9Dqks5vSDjogaJpZM4Y2gc9> .

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ncdc, smarterclayton, soggiest

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• plugin/pkg/admission/OWNERS [smarterclayton]
• test/OWNERS [ncdc,smarterclayton]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment