This repository has been archived by the owner on Aug 14, 2020. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 146
spec: add ExitPolicy type in pod manifest. #500
Closed
Closed
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -102,5 +102,6 @@ | |
"name": "ip-address", | ||
"value": "10.1.2.3" | ||
} | ||
] | ||
], | ||
"exitPolicy": "onAnyFailure" | ||
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,57 @@ | ||
// Copyright 2015 The appc Authors | ||
// | ||
// Licensed under the Apache License, Version 2.0 (the "License"); | ||
// you may not use this file except in compliance with the License. | ||
// You may obtain a copy of the License at | ||
// | ||
// http://www.apache.org/licenses/LICENSE-2.0 | ||
// | ||
// Unless required by applicable law or agreed to in writing, software | ||
// distributed under the License is distributed on an "AS IS" BASIS, | ||
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | ||
// See the License for the specific language governing permissions and | ||
// limitations under the License. | ||
|
||
package types | ||
|
||
import ( | ||
"encoding/json" | ||
"fmt" | ||
) | ||
|
||
type ExitPolicy string | ||
|
||
var validPolicies = map[ExitPolicy]struct{}{ | ||
"untilAll": struct{}{}, | ||
"onAny": struct{}{}, | ||
"onAnyFailure": struct{}{}, | ||
} | ||
|
||
type exitPolicy ExitPolicy | ||
|
||
func (e *ExitPolicy) UnmarshalJSON(data []byte) error { | ||
var ep exitPolicy | ||
if err := json.Unmarshal(data, &ep); err != nil { | ||
return err | ||
} | ||
ee := ExitPolicy(ep) | ||
if err := ee.assertValid(); err != nil { | ||
return err | ||
} | ||
*e = ee | ||
return nil | ||
} | ||
|
||
func (e ExitPolicy) MarshalJSON() ([]byte, error) { | ||
if err := e.assertValid(); err != nil { | ||
return nil, err | ||
} | ||
return json.Marshal(exitPolicy(e)) | ||
} | ||
|
||
func (e ExitPolicy) assertValid() error { | ||
if _, ok := validPolicies[e]; !ok { | ||
return fmt.Errorf("invalid exit policy %q", string(e)) | ||
} | ||
return nil | ||
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,34 @@ | ||
// Copyright 2015 The appc Authors | ||
// | ||
// Licensed under the Apache License, Version 2.0 (the "License"); | ||
// you may not use this file except in compliance with the License. | ||
// You may obtain a copy of the License at | ||
// | ||
// http://www.apache.org/licenses/LICENSE-2.0 | ||
// | ||
// Unless required by applicable law or agreed to in writing, software | ||
// distributed under the License is distributed on an "AS IS" BASIS, | ||
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | ||
// See the License for the specific language governing permissions and | ||
// limitations under the License. | ||
|
||
package types | ||
|
||
import ( | ||
"testing" | ||
) | ||
|
||
func TestGoodExitPolicy(t *testing.T) { | ||
for e := range validPolicies { | ||
if err := e.assertValid(); err != nil { | ||
t.Errorf("good exit policy failed: %v", err) | ||
} | ||
} | ||
} | ||
|
||
func TestBadExitPolicy(t *testing.T) { | ||
e := ExitPolicy("bad") | ||
if err := e.assertValid(); err == nil { | ||
t.Errorf("bad exit policy valid: %v", err) | ||
} | ||
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First: Kubernetes is assuming "untilAll", and we resisted adding this for lack of really concrete use-cases. My instinct is that it SOUNDS cool, but isn't that useful IRL. As far as I know we have no such equivalent internally. If any app container exits with failure, we know the pod is doomed to fail, but we let the other containers finish.
But I'm going to assume you have a concrete set of use-cases that justify this (you should write them down in this PR description) or else you would not be adding hypothetical complexity.
I just went to refresh on the state of the spec, and I realize there is no (what kubernetes calls)
restartPolicy
. Is this supposed to be an analog of that? I think it's interesting to contrast the approaches.Kubernetes defines:
Superficially kube's
RestartAlways
feels the same asuntilAll
here. But here's the rub - the definition of untilAll doesn't actually say anything about restart. Is that part of the policy here or is that governed somewhere else that I am not seeing?I'll not write much more now, because I have asked enough questions that I am probably attacking a straw man.
From a functional POV I think the concepts that matter to a user are "when does my container get restarted?" and "what does that mean for the fate of my pod?", but this only answers the latter, and only partially.
From an API usability POV I think it might be clearer to express these things "in the positive". E.g. I think a "RunPolicy" would be clearer (RunForever, RunToCompletion, RunOnce), and I sort of wish Kubernetes had done it that way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@thockin Actually that's part of the plan to implement k8s' restart policy in rkt
Basically as we are using systemd to launch rkt pods, my original plan is to use systemd's restart policy, and combined with this pod exit policy.
But I see your point, and we actually shouldn't make something just to ease the implementation... I am thinking to change this to restart policy, and implement it in the runtime itself. Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Think a little bit more on this, and I found that a
RestartPolicy
would imply that the runtime islong running
, otherwise if the runtime get's killed, nothing can enforce the restart policy (e.g. kill a pod after killing kubelet, pod is not restarted)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any policy around exit/restart needs something to babysit, right? There's not a way (AFAIK) to tell the OS to kill process B when process A dies (short of SIGCHLD which is a stretch)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can do that with systemd service's dependency though.
My point is if the thing(or runtime) that launches the pod is not
PID1
, then the restart policy will not be enforced in some cases.But maybe that's ok for now as we can limiting the scope of the restart policy, e.g. we assume the runtime is always there, and we don't consider what if the runtime gets killed.
People can just let
PID1
to monitor the runtime, when the runtime fails, we treat it in a like a machine crash, and restart the runtime anyway(which will consequently restarts the pod).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We've made the argument that "userspace is unreliable" in many arguments with Kernel folks, but their pushback (and rightly so) is "make it more reliable". There will always be corner cases, but there has to be a turtle at the bottom, and that turtle can't always be the kernel. In this case, I think kernel includes systemd - it really does fancy itself as important as the kernel.
So define the behavior you think is correct, and engineer towards a good enough answer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, I am happy with changing this to restart policy. Waiting for other maintainers' feedback.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please note that I am not saying you should change it to be like
kubernetes. Consider it in fresh light. I thing RestartPolicy is clearer
than ExitPolicy, but I think RunPolicy might be even better.
On Fri, Sep 25, 2015 at 4:40 PM, Yifan Gu notifications@github.com wrote:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like to have something than empty here :) Any thoughts/votes on
ExitPolicy
vsRestartPolicy
vsRunPolicy
?@jonboulle @vbatts @philips ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ExecPolicy ?
On Oct 15, 2015 5:59 PM, "Yifan Gu" notifications@github.com wrote: