Please just wait for events, and don't add this field here?

Hrm, I think this is different. I think this is so that the (for example) the replication controller can say why when it deletes a pod.

--brendan

@dchen1107 and @vishh are already working on things related to this, and @lavalamp is working on events. I'll assign #1370 to @dchen1107.

See also my last comment in #139. Termination info will go into ContainerStateTerminated.

Hrm, I think this is different. I think this is so that the (for example) the replication controller can say why when it deletes a pod.

No, that should be an event, too.

It can be an event, but it also needs to be things that the client can pass in. Since the client may know why independent of the k8s API (e.g. upstream roll out, whatever)

So yes, there is a replication controller event, but there should also be a reason associated with the pod.

--brendan

also @bgrant0607 this is pod level, not container level. ContainerStateTerminated seems to be container level information.

--brendan

(and I chatted w/ Dawn about this, and we collaboratively identified this as a thing that she wasn't doing right now...)

If client wants to set some sort of information, client should make an event, not write to this field.

I think we do want to let people write a status message. I think that should be an event. We may want to cache the most recent one and expose it in PodState, but I'd rather we get the events hooked up and do the caching separately.

I updated #1370 with latest information. I believe @brendandburns is trying to convey deleted pod status and reasons, which is a separate issue and should fork from #1370.

@brendandburns: @lavalamp's point is that we should use event to explain why a pod is terminated & deleted.

Hrm, I think that is putting too much burden on the end user to make 2 api
calls instead of one.

--brendan

On Wed, Nov 5, 2014 at 3:56 PM, Daniel Smith notifications@github.com
wrote:

If client wants to set some sort of information, client should make an
event, not write to this field.

I think we do want to let people write a status message. I think that
should be an event. We may want to cache the most recent one and expose it
in PodState, but I'd rather we get the events hooked up and do the caching
separately.

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

yes, Dawn is right. This is deleted pod status and reason.

--brendan

On Wed, Nov 5, 2014 at 3:59 PM, Brendan Burns bburns@google.com wrote:

Hrm, I think that is putting too much burden on the end user to make 2 api
calls instead of one.

--brendan

On Wed, Nov 5, 2014 at 3:56 PM, Daniel Smith notifications@github.com
wrote:

If client wants to set some sort of information, client should make an
event, not write to this field.

I think we do want to let people write a status message. I think that
should be an event. We may want to cache the most recent one and expose it
in PodState, but I'd rather we get the events hooked up and do the caching
separately.

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

Yes, this is pod level reason, status, and events, not container level. For container level, I already update #1370 with the latest status.

Hrm, I think that is putting too much burden on the end user to make 2 api calls instead of one.

How is it two api calls? it's pretty easy to make an event.

Ok, thanks for the explanation. I'm fine with this. It needs to be added to the actual APIs. In v1beta3, it belongs in type PodStatus.

Yes, we also need events and we also need the container-level details.

Ok, updated for all apis since this seems acceptable to folks. ptal.

Thanks!
--brendan

verify-gofmt barfed. Please run gofmt.

This is now fixed. I can have mergez?