10:41 a.m.
New subject: please review: Replication Status Message Improvements
Mark Reynolds wrote:
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
10:54 a.m.
New subject: 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(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-leave(a)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.fedoraproje...
11:53 a.m.
New subject: 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
12:19 p.m.
New subject: 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(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-leave(a)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.fedoraproje...
11:08 a.m.
New subject: 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(a)lists.fedoraproject.org
To unsubscribe send an email to 389-devel-leave(a)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.fedoraproje...
11:17 a.m.
New subject: 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(a)lists.fedoraproject.org
>> To unsubscribe send an email to 389-devel-leave(a)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.fedoraproje...
> _______________________________________________
> 389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-leave(a)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.fedoraproje...
11:36 a.m.
New subject: 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(a)lists.fedoraproject.org
>> To unsubscribe send an email to 389-devel-leave(a)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.fedoraproje...
> _______________________________________________
> 389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-leave(a)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.fedoraproje...
3:02 a.m.
New subject: please review: Replication Status Message Improvements
On 12 Jun 2019, at 17:36, Mark Reynolds <mreynolds(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to 389-devel-leave(a)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.fedoraproje...
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
10 a.m.
New subject: please review: Replication Status Message Improvements
On 6/13/19 4:02 AM, William Brown wrote:
> On 12 Jun 2019, at 17:36, Mark Reynolds <mreynolds(a)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(a)lists.fedoraproject.org
>> To unsubscribe send an email to 389-devel-leave(a)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.fedoraproje...
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs
> _______________________________________________
> 389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-leave(a)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.fedoraproje...
2:30 a.m.
New subject: please review: Replication Status Message Improvements
On 13 Jun 2019, at 17:00, Mark Reynolds <mreynolds(a)redhat.com>
wrote:
On 6/13/19 4:02 AM, William Brown wrote:
>
>> On 12 Jun 2019, at 17:36, Mark Reynolds <mreynolds(a)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(a)lists.fedoraproject.org
>> To unsubscribe send an email to 389-devel-leave(a)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.fedoraproje...
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs
> _______________________________________________
> 389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-leave(a)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.fedoraproje...
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
1810
days inactive
1812
days old
389-devel@lists.fedoraproject.org
10 comments
4 participants
participants (4)
-
Mark Reynolds -
Rob Crittenden -
thierry bordaz -
William Brown