> On 12 Jun 2019, at 11:27, thierry bordaz <tbor...@redhat.com> wrote:
>
>
>
> 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.
This could be an excellent approach to support a human and json status in
parallel - given that we can very cheaply provide both, and then we satisfy a
broader range of consumers. Great idea, I support this.
>
> 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-le...@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-le...@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-le...@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
