On 2/7/19 5:32 PM, Fox, Kevin M wrote:
k8s only supports the json driver too. So if its the end goal, sticking to that might be easier.
Cool then - the only big difference being the path, it shouldn't be that hard: docker outputs its json directly in a container-related path, while podman needs a parameter for it (in tripleo world, I've set it to /var/lib/containers/stdouts - we can change it if needed). Oh, not to mention the format - podman doesn't output a proper JSON, it's more a "kubernetes-like-ish" format iiuc[1]... A first patch has been merged by the way: https://review.openstack.org/635437 A second is waiting for reviews: https://review.openstack.org/635438 And a third will hit tripleo-heat-templates once we get the new paunch, in order to inject "--container-log-path /var/log/containers/stdouts". I suppose it would be best to push a parameter in heat (ContainerLogPath for example), I'll check how to do that and reflect its value in docker-puppet.py. Cheers, C. [1] https://github.com/containers/libpod/issues/2265#issuecomment-461060541
Thanks, Kevin ________________________________________ From: Cédric Jeanneret [cjeanner@redhat.com] Sent: Wednesday, February 06, 2019 10:11 PM To: openstack-discuss@lists.openstack.org Subject: Re: [TripleO] containers logging to stdout
Hello,
I'm currently testing things, related to this LP: https://bugs.launchpad.net/tripleo/+bug/1814897
We might hit some issues: - With docker, json-file log driver doesn't support any "path" options, and it outputs the files inside the container namespace (/var/lib/docker/container/ID/ID-json.log)
- With podman, we actually have a "path" option, and it works nice. But the json-file isn't a JSON at all.
- Docker supports journald and some other outputs
- Podman doesn't support anything else than json-file
Apparently, Docker seems to support a failing "journald" backend. So we might end with two ways of logging, if we're to keep docker in place.
Cheers,
C.
On 2/5/19 11:11 AM, Cédric Jeanneret wrote:
Hello there!
small thoughts: - we might already push the stdout logging, in parallel of the current existing one
- that would already point some weakness and issues, without making the whole thing crash, since there aren't that many logs in stdout for now
- that would already allow to check what's the best way to do it, and what's the best format for re-usability (thinking: sending logs to some (k)elk and the like)
This would also allow devs to actually test that for their services. And thus going forward on this topic.
Any thoughts?
Cheers,
C.
On 1/30/19 11:49 AM, Juan Antonio Osorio Robles wrote:
Hello!
In Queens, the a spec to provide the option to make containers log to standard output was proposed [1] [2]. Some work was done on that side, but due to the lack of traction, it wasn't completed. With the Train release coming, I think it would be a good idea to revive this effort, but make logging to stdout the default in that release.
This would allow several benefits:
* All logging from the containers would en up in journald; this would make it easier for us to forward the logs, instead of having to keep track of the different directories in /var/log/containers
* The journald driver would add metadata to the logs about the container (we would automatically get what container ID issued the logs).
* This wouldo also simplify the stacks (removing the Logging nested stack which is present in several templates).
* Finally... if at some point we move towards kubernetes (or something in between), managing our containers, it would work with their logging tooling as well.
Any thoughts?
[1] https://specs.openstack.org/openstack/tripleo-specs/specs/queens/logging-std...
[2] https://blueprints.launchpad.net/tripleo/+spec/logging-stdout-rsyslog
-- Cédric Jeanneret Software Engineer DFG:DF
-- Cédric Jeanneret Software Engineer DFG:DF