[389-devel] Re: Logging future direction and ideas.

> On 22 May 2019, at 22:36, Ludwig Krispenz <lkrispen@redhat.com> wrote:
>
>
> On 05/17/2019 12:44 AM, William Brown wrote:
>
> I think this would be a "final goal", so to formalise the stages:
>
> * Add build tooling and a simple (dummy) log thread as a "getting started". Supplement with documentation on wiki.
> * Fill-in the log thread to support an "operation log", and add basic operation log hooks in the server.
> * Fill in more operation log points in the server to build detail
> * change slapi_log_err to log to the new rust thread, continue to generate error file
> * change slapi_log_audit to log to the new rust thread, continue to generate audit file
> * change slapi_log_access to log to the new rust thread, continue to generate access file.
> * remove former logging code
>
>>> I wonder if we really could have one api eg slapi_log_* and different implementations, keep the current, implement a new one and allow to chose
>> I don't think I understand this comment, could you explain a bit more what you have in mind?
> what I wanted to say is that right now for logging we have a split in "what" and "how", a function wants to log something calls slapi_log_* and provides the loglevel, type (_err, _access), and information (formatstring and params). It does not know or care about log buffering, log rotation, they could even all go to the same file, if it is a dedicated thread or ....
>
> If we want to change logging I would like to keep this separation, and if we want to concentrate on performance we should first address the "how" part, doin all together might be too big a task and too much work. And we would not have to throw away the current impelmentation, it could be configured "how" slapi_log _* perform theit task.

Sounds good. I think (?) that we agree on the design and the approach to coding this then, including the configuring the "how". Perhaps to be more specific, you'd amend the goal as:

> * Add build tooling and a simple (dummy) log thread as a "getting started". Supplement with documentation on wiki.
> * Fill-in the log thread to support an "operation log", and add basic operation log hooks in the server.
> * Fill in more operation log points in the server to build detail
> * change slapi_log_err to log to the new rust thread, continue to generate error file
> * change slapi_log_audit to log to the new rust thread, continue to generate audit file
> * change slapi_log_access to log to the new rust thread, continue to generate access file.

^ These three would become:

* Add a configuration item for async or legacy log processing for the slapi_log_* types, default to "legacy".
* Once more confident, default to "async" for slapi_log_* to use the new rust thread

> * remove former logging code


Is that what you had in mind?


> _______________________________________________
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-leave@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs
_______________________________________________
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org