Ah, this was a regression due to #4373. It's very harmful for RestartPolicyNever pods, slightly less important for RestartAlways.

@bgrant0607 I'd like to bump this back to P1, it makes run once pods impossible to view the logs on.

Are you using Elasticsearch cluster level logging?
I have peen pondering the idea of producing a pod that makes it easy to browse the logs of current and recent pods through a web interface by fetching the information from Elasticsearch and then cross-referencing with the master to map pods to Docker container IDs etc.
Would that be useful for you? If yes, I can make that a priority after I nail the end to end test for cluster level logging?

We are not, quite yet - we're trying to have both the simpler level and the higher level work at the same time (so you can do streaming without ElasticSearch, and if you have ES you get the better experience).

----- Original Message -----

Are you using Elasticsearch cluster level logging?
I have peen pondering the idea of producing a pob that makes it easy to
browse the logs of current and recent pods through a web interface by
fetching the information from Elasticsearch and then cross-referencing with
the master to map pods to Docker container IDs etc.
Would that be useful for you? If yes, I can make that a priority after I nail
the end to end test for cluster level logging?

---

Reply to this email directly or view it on GitHub:
#4640 (comment)

But we do want to consume it.

----- Original Message -----

We are not, quite yet - we're trying to have both the simpler level and the
higher level work at the same time (so you can do streaming without
ElasticSearch, and if you have ES you get the better experience).

----- Original Message -----

Are you using Elasticsearch cluster level logging?
I have peen pondering the idea of producing a pob that makes it easy to
browse the logs of current and recent pods through a web interface by
fetching the information from Elasticsearch and then cross-referencing with
the master to map pods to Docker container IDs etc.
Would that be useful for you? If yes, I can make that a priority after I
nail
the end to end test for cluster level logging?

---

Reply to this email directly or view it on GitHub:
#4640 (comment)

yes, #4373 adds the restriction to only running container, and we should provide ability to view logs of pod in failed state. But the previous way is too ad hoc. When you view the log, you could view the running one, or previous failing one right before Kubelet restart one when policy is RestartAlways.

@saad-ali

@vishh

@smarterclayton Priority bumped up. Agree that #4373 was a regression.

New algorithm, always find the most recent container attempt and show that?

On Feb 23, 2015, at 4:08 PM, Dawn Chen notifications@github.com wrote:

yes, #4373 adds the restriction to only running container, and we should provide ability to view logs of pod in failed state. But the previous way is too ad hoc. When you view the log, you could view the running one, or previous failing one right before Kubelet restart one when policy is RestartNever.

—
Reply to this email directly or view it on GitHub.

@smarterclayton Yes, we are going to support like this.

I've created an issue #4736 ... if it gets traction I am happy to work on it. I also plan to tweak our Elasticsearch cluster level bring up code to remote the last shread of a GCE specific call (to get the public IP of a service) with the equivalent kubectl call (although this feature would not be needed for a cluster level log viewer).

cc/ @ArtfulCoder

This should be fixed on HEAD

Kubelet does not track the last failed container instance and so this issue isn't fully resolved. Re-opening it.

@dchen1107: I assume you are working on this. Can you confirm?

Ping @dchen1107

Yes, just re-assign it to me. Will deal it tomorrow.

Since we are now running kube-apiserver and other master components in a pod, will it be possible via some quick shortcut to go directly to the kubelet to read failed kube-apiserver logs when the kube-apiserver itself fails to start?

----- Original Message -----
From: "Dawn Chen" notifications@github.com
To: "GoogleCloudPlatform/kubernetes" kubernetes@noreply.github.com
Cc: "Derek Carr" decarr@redhat.com
Sent: Tuesday, April 14, 2015 8:21:39 PM
Subject: Re: [kubernetes] Feature request: add ability to view logs of pod in failed state (#4640)

Yes, just re-assign it to me. Will deal it tomorrow.

Reply to this email directly or view it on GitHub:
#4640 (comment)

Status: @dchen1107 has made some progress, but other issues have preempted this, so it won't be done for a couple weeks.

We can assist if necessary.