Wednesday, June 12, 2019

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

On 6/12/19 9:22 AM, Ludwig Krispenz 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 ?
The BZ mention replicaLastUpdateStatus (like "last update status: Error
(18) Replication error acquiring replica: Incremental update transient
error. Backing off, will retry update later. (transient error)")

I agree it is good idea to provide a json status. Should it replaces the
"human readable" format with a json format I would prefer to be
compatible with a new status attribute replicaLastUpdateStatusJson.

theirry
>
> 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.
>>
>> Thoughts?
>>
>> Thanks,
>>
>> Mark
>> _______________________________________________
>> 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
>
_______________________________________________
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

No comments:

Post a Comment