[389-devel] 389 DS nightly 2019-06-13 - 95% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2019/06/13/report-389-ds-base-1.4.1.3-20190612gitb4e585f.fc30.x86_64.html ___ 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] Re: please review: Replication Status Message Improvements
On 6/12/19 12:53 PM, Rob Crittenden wrote: Mark Reynolds wrote: On 6/12/19 11:41 AM, Rob Crittenden wrote: Mark Reynolds wrote: http://www.port389.org/docs/389ds/design/repl-agmt-status-design.html conn_error is 0 in all the examples. What would this be used for? Well there are two type of errors that can occur. One is a replication error (missing CSN, replica busy, etc), and the other type is a connection/LDAP failure (can not contact server, invalid credentials, no such object, etc). This is just how its currently designed in the code, so I carried it forward into the JSON object. Ok. What about compatibility with older versions of 389-ds, particularly tools that read replication status? Are they going to blow up with the new status format? With the new design, yes. But the old design is broken IMHO. At some point we need to improve this, and it will be disruptive whether it's implemented today or next year. We could always just implement the JSON attribute, but then we will have a discrepancy between the two attributes. I'd prefer not to do that as the whole point of all this is to improve the clarity of the agreement status. Mark rob ___ 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
[389-devel] Re: please review: Replication Status Message Improvements
Mark Reynolds wrote: > > On 6/12/19 11:41 AM, Rob Crittenden wrote: >> Mark Reynolds wrote: >>> http://www.port389.org/docs/389ds/design/repl-agmt-status-design.html >> conn_error is 0 in all the examples. What would this be used for? > Well there are two type of errors that can occur. One is a replication > error (missing CSN, replica busy, etc), and the other type is a > connection/LDAP failure (can not contact server, invalid credentials, no > such object, etc). This is just how its currently designed in the code, > so I carried it forward into the JSON object. Ok. What about compatibility with older versions of 389-ds, particularly tools that read replication status? Are they going to blow up with the new status format? rob ___ 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] Re: please review: Replication Status Message Improvements
Sorry Mark, my email was confusing. First you make a good point. Giving extra info does not hurt. I just noticed that replication status contains two RC (ldap and replication), while init status contains three RC (ldap, replication, connection). So the json struct should differ from regular_replication and init_replication status. On 6/12/19 6:17 PM, Mark Reynolds wrote: On 6/12/19 12:08 PM, thierry bordaz wrote: Hi Mark, Looking very good to me. For replication status there is either ldaprc or replrc. The message is self explaining if it is a LDAP or replication error. IMHO I think json could only contain 'repl_status' that can contain ldaprc or replrc. Well I was thinking it didn't hurt to have separate error code elements in the JSON object, and it allows a client to know what type of error it is without having to interpret the message string. This "could" be useful to an Admin which is why I added it. Maybe its not that useful, but like I said I don't think it hurts. For init status, it exists ldaprc, connrc and replrc. I think it would be good to have all three. Wait :-) So now you want the error code object elements? Either way good point, the JSON object should have all three error code types (unless it is decided to remove all the error code elements). Thanks, Mark best regards thierry On 6/12/19 5:36 PM, Mark Reynolds wrote: http://www.port389.org/docs/389ds/design/repl-agmt-status-design.html ___ 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 ___ 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] Re: please review: Replication Status Message Improvements
On 6/12/19 12:08 PM, thierry bordaz wrote: Hi Mark, Looking very good to me. For replication status there is either ldaprc or replrc. The message is self explaining if it is a LDAP or replication error. IMHO I think json could only contain 'repl_status' that can contain ldaprc or replrc. Well I was thinking it didn't hurt to have separate error code elements in the JSON object, and it allows a client to know what type of error it is without having to interpret the message string. This "could" be useful to an Admin which is why I added it. Maybe its not that useful, but like I said I don't think it hurts. For init status, it exists ldaprc, connrc and replrc. I think it would be good to have all three. Wait :-) So now you want the error code object elements? Either way good point, the JSON object should have all three error code types (unless it is decided to remove all the error code elements). Thanks, Mark best regards thierry On 6/12/19 5:36 PM, Mark Reynolds wrote: http://www.port389.org/docs/389ds/design/repl-agmt-status-design.html ___ 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 ___ 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] Re: please review: Replication Status Message Improvements
Hi Mark, Looking very good to me. For replication status there is either ldaprc or replrc. The message is self explaining if it is a LDAP or replication error. IMHO I think json could only contain 'repl_status' that can contain ldaprc or replrc. For init status, it exists ldaprc, connrc and replrc. I think it would be good to have all three. best regards thierry On 6/12/19 5:36 PM, Mark Reynolds wrote: http://www.port389.org/docs/389ds/design/repl-agmt-status-design.html ___ 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
[389-devel] Re: please review: Replication Status Message Improvements
On 6/12/19 11:41 AM, Rob Crittenden wrote: Mark Reynolds wrote: http://www.port389.org/docs/389ds/design/repl-agmt-status-design.html conn_error is 0 in all the examples. What would this be used for? Well there are two type of errors that can occur. One is a replication error (missing CSN, replica busy, etc), and the other type is a connection/LDAP failure (can not contact server, invalid credentials, no such object, etc). This is just how its currently designed in the code, so I carried it forward into the JSON object. Otherwise this looks ok to me. I assume we'll need to do coordinate releases with IPA so the new format can be handled properly? I guess once the design is firmed up we can start on the IPA side and hopefully handle both styles of messages. rob ___ 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
[389-devel] Re: please review: Replication Status Message Improvements
Mark Reynolds wrote: > http://www.port389.org/docs/389ds/design/repl-agmt-status-design.html conn_error is 0 in all the examples. What would this be used for? Otherwise this looks ok to me. I assume we'll need to do coordinate releases with IPA so the new format can be handled properly? I guess once the design is firmed up we can start on the IPA side and hopefully handle both styles of messages. rob ___ 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] please review: Replication Status Message Improvements
http://www.port389.org/docs/389ds/design/repl-agmt-status-design.html ___ 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] Re: Replication agreement status messages: JSON or text?
On 6/12/19 5:48 AM, William Brown wrote: On 12 Jun 2019, at 11:27, thierry bordaz 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-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 ___ 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] Re: Replication agreement status messages: JSON or text?
> On 12 Jun 2019, at 11:27, thierry bordaz 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
[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-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
[389-devel] Re: Replication agreement status messages: JSON or text?
> On 12 Jun 2019, at 09:22, 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 ? > > 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@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 > > -- > 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@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
[389-devel] Re: Replication agreement status messages: JSON or text?
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. 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 -- 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@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