On 6/12/19 5:48 AM, William Brown wrote:
>
>> On 12 Jun 2019, at 11:27, thierry bordaz <tbordaz@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.
Ludwig, just to clarify I am not referring to logging but to the status
attribute in the agreement entry: replicaLastUpdateStatus
Going back to the topic at hand, it looks like the consensus is both
text and JSON :-) Improve existing text messages (use Error (%d),
Warning (%d), and Info), and then add a second attribute with a JSON
text string that can be parsed by clients. I will write up a design doc
and send it out for review...
>
>> 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
> —
> 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
_______________________________________________
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