[Pulp-dev] Proposal to change default logging to console in Pulp 3

[Eric Helms]

Thanks for the quick discussion. I went ahead and opened an issue and
accompanying PR for the work to make this change for y'all to consider.

On Wed, Jul 25, 2018 at 10:59 AM, Daniel Alley <dalley at redhat.com> wrote:

> Not to say syslog is dead, it's especially useful for clustered installs
>> which need fancier logging like centralization or off-site replication, etc.
>
>
> And a lot of people who do use syslog are just telling journald to forward
> logs there, in which case, console logging is still a good default.
>
> On Wed, Jul 25, 2018 at 10:42 AM, Brian Bouterse <bbouters at redhat.com>
> wrote:
>
>> I think console logging is also probably the right logging default in non
>> containerized environments too. The majority of OSes Pulp will run on will
>> run systemd which has it's logging facilities reading from stdout and
>> stderr [0]. So for the majority of non-containerized userbase systemd is
>> their logging system not syslog. Not to say syslog is dead, it's especially
>> useful for clustered installs which need fancier logging like
>> centralization or off-site replication, etc. Those users can take the extra
>> step to configure logging to syslog if they apply a bit of extra config
>> after https://pulp.plan.io/issues/3879 is fixed.
>>
>> It also being the expected logging for containerized environments makes
>> me think we should switch Pulp3 to console logging as the default. What do
>> you think?
>>
>> [0]: https://www.freedesktop.org/software/systemd/man/systemd-jou
>> rnald.service.html#Description
>>
>>
>> On Wed, Jul 25, 2018 at 10:31 AM, Eric Helms <ehelms at redhat.com> wrote:
>>
>>> You actually can run with console logging today. There is a bug where if
>>> you are in an environment without syslog and enable console logging you
>>> will get errors, see https://pulp.plan.io/issues/3879
>>>
>>> Since background running typically translates to systemd based, perhaps
>>> considering making logging type configurable as an environment variable or
>>> command line option to set it per service. For example, perhaps you want to
>>> run workers in the background but the main application server in your
>>> console?
>>>
>>>
>>> On Wed, Jul 25, 2018 at 9:17 AM, David Davis <daviddavis at redhat.com>
>>> wrote:
>>>
>>>> I definitely think that we should support console logging (and it looks
>>>> like we currently don’t) but I’m a bit hesitant to make it the default. I
>>>> think right now a majority of non-dev users will be running these services
>>>> in the background. But I could see perhaps one day where Pulp is mostly run
>>>> in containers where console logging would be the better default.
>>>>
>>>> David
>>>>
>>>>
>>>> On Wed, Jul 25, 2018 at 8:17 AM Eric Helms <ehelms at redhat.com> wrote:
>>>>
>>>>> Howdy,
>>>>>
>>>>> As I understand things, the default logging in Pulp 3 is set to
>>>>> syslog. I am proposing changing this to be console by default and
>>>>> optionally letting users configure syslog. I think these days console as a
>>>>> default makes general sense for running things in a simple terminal, or as
>>>>> a developer. Further, the natural way to log in a container based
>>>>> environment is to log to stdout. The use of syslog makes sense in a
>>>>> traditional systemd based deployment which can be configured by users as
>>>>> needed.
>>>>>
>>>>>
>>>>> - Eric
>>>>> _______________________________________________
>>>>> Pulp-dev mailing list
>>>>> Pulp-dev at redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> Pulp-dev mailing list
>>> Pulp-dev at redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>>>
>>
>> _______________________________________________
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180725/6bc9b487/attachment.htm>