[389-devel] Re: Replication agreement status messages: JSON or text?

[William Brown]

>  On 12 Jun 2019, at 09:22, Ludwig Krispenz <lkrispen(a)redhat.com&gt;
> wrote:
>  
>  Hi Mark,
>  
>  On 06/11/2019 08:15 PM, Mark Reynolds wrote:
> > I am currently working on a revision of replication agreement status messages. 
> Previously we logged the status like so:
> > 
> >    Error (%d) - message (sub-message) ...
>  just to get it clear what you suggest, I was a bit confused about first.
>  
>  Do you talk about logging (as in the error log) or about the value of the
> replicaLastUpdateStatus attribute ?
>  
>  For logging into the error log I prefer to keep the current, "readable" format
> - until we do a real rework of logging.
>  For the storage of a state in the agreement I think switching to the json object is ok
> > 
> > If Error was set to 0 it meant success, but this caused confusion because of the word
> "Error".  So I am working on changing this.
> > 
> > There are two options here: change the static "Error" text to be dynamic:
> "Info", "Warning", or "Error" depending on the state. Or,
> move away from a human friendly text string to a machine friendly simple JSON object. 
> There are pro's and con's to both. I think moving towards a JSON object is the
> correct way - easier to maintain, and easier to be consumed by other applications.  The
> cons are that it is a disruptive change to the previous behavior, and it could be
> confusing to an Admin who might not understand JSON.
> > 
> > This is the basic JSON object I was thinking of
> > 
> >    {"status": "Good|Warning|Bad", "status code":
> NUMBER(aka error code), "date": "2019117485748745Z",
> "message": "Message text"}
> > 
> > or maybe multiple messages (list):
> > 
> >    {"status": "Good|Warning|Bad", "status code":
> NUMBER(aka error code), "date": "2019117485748745Z",
> "message": ["the replication status is...", "Connection error
> 91", "Server Down"]}
> > 
> > 
> > The JSON object can easily be extended without breaking clients, but it's not
> easy to read for a human. 
I'd prefer json because then our tools can parse it, and it means we have better
structured data to work with instead of using regexes. For the new logging I was planning
to use rust serde, but for this you could use libjanson I think for C. 

I really think overall we should be moving to structured messages and logging styles with
json to help give better messages and options for systems like splunk and elk to read from
our status, and for integrators like freeipa to be able to read our statues in a way that
when we change them, we don't immediately break their regex.


> > 
> > Thoughts?
> > 
> > Thanks,
> > 
> > Mark
> > _______________________________________________
> > 389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to 389-devel-leave(a)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/[e-mail]...
>  
>  -- 
>  Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
>  Commercial register: Amtsgericht Muenchen, HRB 153243,
>  Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric
> Shander
>  _______________________________________________
>  389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-devel-leave(a)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/[e-mail]... 
—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs