Open Stack

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-stdout.html
>>
>> [2] https://blueprints.launchpad.net/tripleo/+spec/logging-stdout-rsyslog
>>
>>
>>
> 

-- 
Cédric Jeanneret
Software Engineer
DFG:DF

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190207/2e097f13/attachment.sig>