Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

KEP for critical container feature #912

Open
wants to merge 4 commits into
base: master
from

Conversation

Projects
None yet
7 participants
@CsatariGergely
Copy link

commented Mar 22, 2019

Signed-off-by: Gergely Csatari gergely.csatari@nokia.com

KEP for critical container feature
Signed-off-by: Gergely Csatari <gergely.csatari@nokia.com>
@k8s-ci-robot

This comment has been minimized.

Copy link
Contributor

commented Mar 22, 2019

Hi @CsatariGergely. 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.

@k8s-ci-robot

This comment has been minimized.

Copy link
Contributor

commented Mar 22, 2019

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: CsatariGergely
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: derekwaynecarr

If they are not already assigned, you can assign the PR to them by writing /assign @derekwaynecarr in a comment when ready.

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:

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

@CsatariGergely

This comment has been minimized.

Copy link
Author

commented Mar 22, 2019

@derekwaynecarr
Copy link
Member

left a comment

Thank you for proposing this idea.

Can we discuss this in more detail at a future SIG node meeting so we understand the problems and goals?

Show resolved Hide resolved keps/sig-node/20190333-critical-container.md Outdated
Show resolved Hide resolved keps/sig-node/20190333-critical-container.md
@libesz

This comment has been minimized.

Copy link

commented Mar 22, 2019

@derekwaynecarr You can find some use-cases here: kubernetes/kubernetes#40908
Pod replacement in my mind is the process what is done when all the container including the infra (pause) is terminated and re-created from the PodSpecs.
The idea was that we don't want to introduce a new procedure to "restart" a pod in-place (which i.e. preserves the emptyDir volumes, etc.), instead use the existing terminate and create procedures of the Pod, done by kubelet. Hope our assumptions are correct 🤞 .

Clarifications on Pod replacement
Some clarification on the definition of Pod replacement based
on the pr discussion.

Signed-off-by: Gergely Csatari <gergely.csatari@nokia.com>
@CsatariGergely

This comment has been minimized.

Copy link
Author

commented Mar 25, 2019

@derekwaynecarr Thanks for the comments. To join to the sig-node meeting this week is a bit difficult from CET timezone. Next week I will be closer timezone wise and I will try to join.

@CsatariGergely

This comment has been minimized.

Copy link
Author

commented Apr 2, 2019

Notes from sig-node meeting at 02.04.2019:

  • Sidecar containers KEP1, KEP2 is doing similar in a sense that some containers are differently handled from the pods lifececyle point of view
  • We should check if this provides a solution to our problem
@libesz

This comment has been minimized.

Copy link

commented Apr 25, 2019

Notes from sig-node meeting at 02.04.2019:

* Sidecar containers [KEP1](https://github.com/kubernetes/enhancements/pull/919), [KEP2](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/sidecarcontainers.md) is doing similar in a sense that some containers are differently handled from the pods lifececyle point of view

* We should check if this provides a solution to our problem

Just checked the other KEPs. I believe those are covering different use-cases around lifecycle management, while this one wants to cover failure/recovery scenarios. I would consider this one as independent from specification/implementation PoV.

Reference to KEP-s mentioned in the sig-node meeting
Signed-off-by: Gergely Csatari <gergely.csatari@nokia.com>
@justaugustus

This comment has been minimized.

Copy link
Member

commented Apr 28, 2019

/ok-to-test

@InAnimaTe

This comment has been minimized.

Copy link

commented May 18, 2019

This is a great KEP and I'd love to see it get approved. @CsatariGergely @derekwaynecarr what specifically is being waited for prior to approval?

@CsatariGergely

This comment has been minimized.

Copy link
Author

commented May 21, 2019

Thanks @InAnimaTe :) I would be also interested to figure out what is needed to approve this. I'm available in Barcelona to discuss if that helps.

Changing the state to provisional
However it is nto clar from the KEP process, the initial state of
a KEP should be provisional.
@thockin
Copy link
Member

left a comment

I just want to say that I have heard this request many times, and while I continue to assert that "you're doing it wrong" it seems common enough to consider. I urge you to look for the simplest design that satisfies the preponderance of users.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.