Add post-start hooks

[LK4D4]

part of #20

[wking]

If a post-start hook returns a non-zero exit code, wouldn't we want to
immediately stop the application, tear down the container, and run the
post-stop hooks (i.e. jump to step eight in 1 without running any
further post-start hooks)? Folks who are interested in ignoring exit
codes can always use a wrapper like:

#!/bin/sh
"$@"
exit 0

[LK4D4]

@wking I'm not sure, but maybe.

[wking]

Maybe “application” instead of “user process” and “real process”? See #107.

And the second sentence reads a bit strangely to me. Maybe mirror the pre-start phrasing with something like “For example, sidecar applications could be launched in this hook.”? Although personally I'd rather drop the passive voice and say “For example, this hook could launch sidecar applications”.

[LK4D4]

I don't like sidecar application example. Why you insist on using it?

[wking]

On Mon, Sep 28, 2015 at 03:23:36PM -0700, Alexander Morozov wrote:

+It can be used for notifying user that real process is spawned.

I don't like sidecar application example. Why you insist on using
it?

Because it's concrete and easier to phrase (and that application may
be in a separate container, which may address your concerns). Do you
have another example of when you'd actually care about the “user
application has started” event? Just logging it seems like something
that could be handled by an event stream like ‘runc events’, and not
something that you'd need event-specific hooks for.

[LK4D4]

Adding to consul or to some other discovery tool, register your container internally etc. Apart from this I have real use-case in docker where I need event when I can say client that application is ready. Do you really have plans to start sidecar processes?

[wking]

On Tue, Sep 29, 2015 at 01:33:06PM -0700, Alexander Morozov wrote:

Adding to consul or to some other discovery tool…

Hmm, wouldn't this need the service to be listening on a socket?
Registering it in a post-start hook would be better than registering
it in a pre-start hook, but it would still be too early ;).

Apart from this I have real use-case in docker where I need event
when I can say client that application is ready.

Again, “is ready” is likely to be some time after “we just exec-ed
it”.

Do you really have plans to start sidecar processes?

@julz is working on garden for cloudfoundary 2, and they have
explicit create-container 3 and launch-application 4 steps. He
needs a way to know when the container is safe to exec into so he can
allow/deny launch-application requests. See the “How do we know when
the process is up?” section of 5.

That's not a sidecar container, but it is close to a sidecar
application. And “sidecar” is familiar enough language that I think
it gets the point across without a long-winded explanation ;).

[wking]

On Tue, Sep 29, 2015 at 02:20:06PM -0700, Alexander Morozov wrote:

+The post-start hooks are called after the user process is started.
+It can be used for notifying user that real process is spawned.

There is nothing about "Sidecar application" as well as "sidecar
process" in google, so seems like not so familiar language…

Ah, it looks like the language I was reaching for is “sidekick” 1,
but anyway fair enough on it not being well established.

… cloudfoundry use-case isn't sidecar, but notfiy use-case indeed.

Ah, good catch. But it's still not the notificiation that's special
about the post-start timing (it's the fact that the container is ready
for additional execs). So I'd rather have something like:

For example, this hook could launch additional applications joining
this container.

or if you really want to echo the cloudfoundary use case:

For example, this hook could tell an external manager that it was
safe to launch additional applications joining this container.

I intend to do the former and launch a dummy process with start, then
post-start (or whatever "this container is ready to exec into" tooling
we get) to launch Nginx inside that container. Decoupling the Nginx
application from the main container application lets me upgrade my
binary 2 without killing the container.

[LK4D4]

Fun thing, that actually you don't need process to be started to join container, so use-case is invalid :)

[wking]

On Tue, Sep 29, 2015 at 04:18:53PM -0700, Alexander Morozov wrote:

+It can be used for notifying user that real process is spawned.

Fun thing, that actually you don't need process to be started to
join container, so use-case is invalid :)

I need to know that the container exists ;). If the container
includes a PID namespace (or anything else that's bound to the
container process, the join has to be launched after those bits have
been created. With the lifecycle in 1, that means anything after
step 3, which means that the last hook in a pre-start hook chain would
be a reasonable place for my Nginx stuff and the garden stuff too
(sorry I didn't notice that earlier).

Which gets me back to wondering what post-start is good for :p. Can
you elaborate on why the last hook in a pre-start hook chain wouldn't
work for your “is ready” notification 2, but a post-start hook
would? I think my problem is figuring out what the interesting change
has been, since “we've changed the binary that the application is
running” doesn't seem like a particularly actionable event.

[LK4D4]

Your use-case about container and not about process, that's why pre-start hook is ok for you.
I said you my use-cases before - for registering application as working somewhere, so just namespaces and cgroups isn't enough for such task.
I wonder if you think that only your use-cases are true. Pls, believe mine real as well.

[wking]

On Tue, Sep 29, 2015 at 05:19:20PM -0700, Alexander Morozov wrote:

I said you my use-cases before - for registering application as
working somewhere…

But “we just executed the code” doesn't necessarily map to “it's
working now” does it? Most processes have some startup where they
read config files, open sockets, etc., etc., before they're ready to
start performing their primary function (e.g. serving web requests,
analyzing data files, etc., etc.). So I agree that a pre-start hook
would be a poor place for “this application is ready to do real work”.
I just think that a post-start hook is still not the right place. For
socket-based applications, “the process has created and bound to the
expected address” is probably the right place, but that's not when a
post-start hook would be firing.

I wonder if you think that only your use-cases are true. Pls,
believe mine real as well.

I'm sure your have a real use case, which is why I'm asking for more
details on what that use case is 1. I'm less confident that a
post-start hook is the best solution to your problem, but that may be
just because I don't understand what that problem is :p. Do you have
some code I can look at that demonstrates the problem you're trying to
solve with a post-start hook?

[crosbymichael]

LGTM

[mrunalp]

LGTM

[vbatts]

LGTM

[vbatts]

booo. YOU BEAT ME AGAIN!