While I have in the past argued for some run-once pod setup, I don't have a
concrete use case that has no other workaround at hand. And if we did
something like this we would need to keep it dead simple - dependencies are
gilding we don't really need.

On Sun, Oct 26, 2014 at 10:40 AM, Mark Turansky notifications@github.com
wrote:

Some commentary on "run once" containers: #1589
#1589 #1515
#1515
tl;dr

"run once" containers imply a pod lifecycle. Declaring container
dependencies ignores pod lifecycle and allows arbitrary complexity and
flexibility for application developers ("run many").
Run Once

Add an attribute to the pod manifest containing either one or a list of
docker images to run before the pod's main containers. This is a single
task list to run during pod creation, making this a lifecycle step.
Implied, I think, is success of all tasks for a pod to continue. Also
implied is linear processing because some tasks will require order for
setup/config/init/whatever while others won't, but we cannot know which
without understanding their dependencies. Only some tasks might be required
to complete before some of the pod's containers can be created. I don't
think this is a concurrent design.
Chaining / Container dependencies

A "depends" attribute on the container containing a list of docker images
to run before the current container. These are multiple task lists/chains
before container creation allowing for greater flexibility for application
developers/composers. Containers can be created and come online as their
dependencies are satisfied. I think this way is the concurrent design and
allows arbitrary complexity of composition for the application developer
(including those tasks must be sequential).

{
"apiVersion": "v1beta4",
"kind": "Pod",
"id": "myapp",
"desiredState": {
"manifest": {
"version": "v1beta4",
"id": "myapp",
"containers": [
{
"name": "some-init",
"image": "myapp/something-init"
},
{
"name": "a-task",
"image": "myapp/random-task"
},
{
"name": "main-app",
"image": "myapp/main-app",
"depends": ["some-init", "a-task"]
},
{
"name": "another-container",
"image": "myapp/main-app",
"depends": ["a-task"]
}
]
}
}
}

Reply to this email directly or view it on GitHub
#1996.

@thockin

Frankly, I can't think of any "init" style task that cannot be accomplished in scripts in the container itself by the app developer (except for ordering in pods with many containers). Putting those tasks as "run once" containers (dependencies or otherwise) might better fit the "everything runs in a container" paradigm, but I don't think I would be blocked as the app developer without "run once".

That said, if it is decided that "run once" tasks are necessary, I think there is a stronger case for simple container dependencies over a lifecycle hook.

General inter-container dependencies don't have well-defined semantics on updates and restarts, and would require checkpoints in Kubelet to implement correctly across Kubelet restarts, which we've so far avoided. Additionally, in my experience, this is a very slippery slope with a potentially very wide feature set for things like conditional triggers and error handling. I don't want BPEL in the PodSpec.

I'd prefer to support the most common cases with more constrained mechanisms, and provide adequate extension points for users to implement more sophisticated behavior if they need to.

no need for this issue, then. I'll close it.