Add types for lifecycle events.

I buy the reason param, still not sure on time.  I think we should commit
something and add onto it.  We're coming onto the long weekend, and anyone
who want to hack should be able to build on this.


On Fri, Aug 29, 2014 at 3:33 PM, bgrant0607 <notifications@github.com>
wrote:

> In pkg/api/types.go:
>
> > +// TODO: merge this with liveness probing?
> > +// TODO: pass structured data to these actions, and document that data here.
> > +type Handler struct {
> > +	// One and only one of the following should be specified.
> > +	// Exec specifies the action to take.
> > +	Exec *ExecAction `yaml:"exec,omitempty" json:"exec,omitempty"`
> > +	// HTTPGet specifies the http request to perform.
> > +	HTTPGet *HTTPGetAction `yaml:"httpGet,omitempty" json:"httpGet,omitempty"`
> > +}
> > +
> > +// Lifecycle describes actions that the management system should take in response to container lifecycle
> > +// events.  For all lifecycle handlers, management of the container blocks until the action is complete.
> > +type Lifecycle struct {
> > +	// PostStart is called immediately after a container is created.
> > +	PostStart *Handler `yaml:"postStart,omitempty" json:"postStart,omitempty"`
> > +	// PreUserStop is called immediately before a container is terminated due to an API request.
>
> Some of the context was in #1028
> <https://github.com/GoogleCloudPlatform/kubernetes/pull/1028> .
>
> The API for stopping pods will be used in many, many scenarios, such as:
> restarts of sick containers that still respond to liveness probes, rolling
> updates, emergency wholesale updates, clean host drains, auto-scaling, live
> migration, ... In some of these cases, the user will want to shut down with
> the full notice period, which may allow time for clean shutdown or even for
> a replacement to be spun up. In other cases, they'll want to shutdown more
> rapidly, for instance allowing in-flight requests to be completed, but not
> awaiting a replacement, because the user knows there won't be a
> replacement. In still other cases, they won't want to wait at all, such as
> when killing a misbehaving workload.
>
> What's at least as important as the time parameter is passing a
> client-provided termination reason, as proposed in #137
> <https://github.com/GoogleCloudPlatform/kubernetes/issues/137>. That
> would allow the PreStop (and PostStop when we add it) handler to make a
> reasonable decision about what to do, provided it was a scenario that was
> planned in advance.
>
> --
> Reply to this email directly or view it on GitHub
> <https://github.com/GoogleCloudPlatform/kubernetes/pull/1041/files#r16919363>
> .
>