feature: kubectl logs options about systemk HOT 9 CLOSED

One more option is --since. This makes me think we must consider all logging options.

from systemk.

Also, something I realized during my tests is that if a unit with the same name ran in the past, there's the chance logs are still around which doesn't seem a good thing.

A quick search led me to learn journalctl allows for vacuum the logs but only archived ones, so something like this could work:

journalctl --rotate
journalctl --vacuum-time=1s

from systemk.

Also, something I realized during my tests is that if a unit with the same name ran in the past, there's the chance logs are still around which doesn't seem a good thing.

A quick search led me to learn journalctl allows for vacuum the logs but only archived ones, so something like this could work:

Recreation of pods where the name sticks is usually a thing only when dealing with naked Pods (not under the control of any envelope, such as Deployment) or StatefulSets, eg my-pod-0. But this is enough to justify, I think, some sort of logic here that avoids fetching logs from previous instances of a homonym Pod.

An alternative to what I proposed earlier, is to have the provider enforce journald entries that have been created since after the current Pod instance started. Since the provider has access to informers cache (the current code doesn't have access to the Pod informer but we can change that), we can easily retrieve the starttime attribute and compute based on that.

WDYT @miekg?

from systemk.

Also, something I realized during my tests is that if a unit with the same name ran in the past, there's the chance logs are still around which doesn't seem a good thing.

I don't think this is bad, this could actually be helpful. And anyway if journald works like this we should not jump through hoops to make it work differently.

from systemk.

It's not much about systemd but about the fact that you'll get logs from Pod instances that no longer exist and/or never belonged to you. What if user A runs Pod xyz, prints some data, deletes Pod, and then user B runs a Pod with same name: is it ok for user B to get logs from a workload instance they didn't own? In the containerized Kubernetes world, even when journald is the log sink, it is guaranteed the logs pertain only to the instance of the Pod you're retrieving logs for.

from systemk.

Another alternative, and way more easy, is to append Pod UID to the the systemd unit name, hence guaranteeing uniqueness.

from systemk.

from systemk.

I think I'm too tied to how the kubelet does things and to keep UX parity when possible.

Anyway, I think it's fine to leave it for now and if it becomes a problem later it will be easy to address.

from systemk.

from systemk.