Kubelet needs a way to send results

[thockin]

Idea 1) Track a state per-pod. One such state is "invalid" (for bad input). The kubelet HTTP server can show the state.

Idea 2) Publish results to etcd

These are not mutually exclusive.

[smarterclayton]

Related to #127, #137, and #156. Are there other pieces of information besides state that are related to a container's execution that should be rolled up? Certainly the time that a state transition occurred is relevant. I bring up because we tend to think of this as a three part problem -

1. specific container events which are core to the platform being reported to the core infrastructure (state, exit status)
2. generic container events triggered by other host level monitors (resource threshold exceeded), and possibly host level events (no memory available, swap warnings)
3. making decisions based on 1) or 2) that might feed into the scheduler or replication controllers

At the start, we saw this as a separate logical subsystem (events) with a separate return channel (since this information is essentially untrustworthy in a multi-tenant system), feeding back into an event bus that detached components could react to. However, for 1) in particular I could buy the argument that this is a core mechanism of the master->kubelet system and is separate from a generic event mechanism.

[thockin]

I think you're right that some things are so core that they have to be part
of the primary API. As Kubelet gets more complicated, we really do need to
expose some details about whats going on. We don't really have a state
machine yet, but we will. We don't really have local state yet, but I
think we will.

I think we want the user experience to be centralized - some common tools
or UI or database that shows you everything that has been going on.

On Sat, Jun 28, 2014 at 9:12 PM, Clayton Coleman notifications@github.com
wrote:

Related to #127
#127 and #137
#137. Are there
other pieces of information besides state that are related to a container's
execution that should be rolled up? Certainly the time that a state
transition occurred is relevant. I bring up because we tend to think of
this as a three part problem -

1. specific container events which are core to the platform being reported
   to the core infrastructure (state, exit status)
2. generic container events triggered by other host level monitors
   (resource threshold exceeded), and possibly host level events (no memory
   available, swap warnings)
3. making decisions based on 1) or 2) that might feed into the scheduler
   or replication controllers

At the start, we saw this as a separate logical subsystem (events) with a
separate return channel (since this information is essentially
untrustworthy in a multi-tenant system), feeding back into an event bus
that detached components could react to. However, for 1) in particular I
could buy the argument that this is a core mechanism of the master->kubelet
system and is separate from a generic event mechanism.

Reply to this email directly or view it on GitHub
#285 (comment)
.

[lavalamp]

This keeps coming up. We should prioritize it. See #602...

[erictune]

Kubelet is going to publish events that happen to containers. @lavalamp is working on that.
That also requires that kubelets have a path to write to the API. The ongoing authorization work will allow that.

[dchen1107]

I am going to close this one since kubelet now reports PodStatus, pod related events Node states back upper layers already. There are issues / enhancements filed as separate issues already.