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
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-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....
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
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-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....
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-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....
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-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....
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....
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-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....
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....
On 12 Jun 2019, at 17:36, Mark Reynolds mreynolds@redhat.com wrote:
http://www.port389.org/docs/389ds/design/repl-agmt-status-design.html
Looks great!
Instead of "Success" we could use "Healthy" because replication isn't a success/fail, it's a longterm "good/bad" IE healthy/failing state. So perhaps instead of success/warning/error, we have "healthy/delayed/warning/error" instead? Additionally, on warning + error, we log those to error log by default so that an admin can "see" past errors, and when they "resolve" a resolution is also posted to the error log too?
Date is json should be ISO 8601 format instead?
2019-06-13T07:53:20+00:00
I hope this helps!
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....
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs
On 6/13/19 4:02 AM, William Brown wrote:
On 12 Jun 2019, at 17:36, Mark Reynolds mreynolds@redhat.com wrote:
http://www.port389.org/docs/389ds/design/repl-agmt-status-design.html
Looks great!
Instead of "Success" we could use "Healthy" because replication isn't a success/fail, it's a longterm "good/bad" IE healthy/failing state. So perhaps instead of success/warning/error, we have "healthy/delayed/warning/error" instead? Additionally, on warning + error, we log those to error log by default so that an admin can "see" past errors, and when they "resolve" a resolution is also posted to the error log too?
Really there are only three states: working, delayed, and broken. What about: Good, Warning, Error? FYI if this does not get pushed today we will a very important deadline (in fact it will mean all the bugs slated for the next release will be missed!!!!) So I don't want to keep debating "names" for much longer...
Date is json should be ISO 8601 format instead?
2019-06-13T07:53:20+00:00
I will look into this, but we are running our of time as I mentioned above. Maybe I will just drop the date for now...
I hope this helps!
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....
— 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....
On 13 Jun 2019, at 17:00, Mark Reynolds mreynolds@redhat.com wrote:
On 6/13/19 4:02 AM, William Brown wrote:
On 12 Jun 2019, at 17:36, Mark Reynolds mreynolds@redhat.com wrote:
http://www.port389.org/docs/389ds/design/repl-agmt-status-design.html
Looks great!
Instead of "Success" we could use "Healthy" because replication isn't a success/fail, it's a longterm "good/bad" IE healthy/failing state. So perhaps instead of success/warning/error, we have "healthy/delayed/warning/error" instead? Additionally, on warning + error, we log those to error log by default so that an admin can "see" past errors, and when they "resolve" a resolution is also posted to the error log too?
Really there are only three states: working, delayed, and broken. What about: Good, Warning, Error? FYI if this does not get pushed today we will a very important deadline (in fact it will mean all the bugs slated for the next release will be missed!!!!) So I don't want to keep debating "names" for much longer...
Look, anything that isn't so ... I dunno. "Single action" focused but conveys that the service is operating as expected. I think good may not be the right term either from an admin point of view. So Healthy/Warning, Operational/Delayed, Green/Amber/Red also works from a monitoring case.
Date is json should be ISO 8601 format instead?
2019-06-13T07:53:20+00:00
I will look into this, but we are running our of time as I mentioned above. Maybe I will just drop the date for now...
Fair, we can add this later then - after all it's json so we can change it without breaking things.
Just as a mild concern, I know that there are RH deadlines to meet, but I don't like that leaking into rushing work upstream :(
I hope this helps!
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....
— 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....
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs
389-devel@lists.fedoraproject.org