389-ds-base

#50447 Issue 49602 - Revise replication status messages
Closed by spichugi. Opened by mreynolds.
mreynolds/389-ds-base ticket49602  into  master

Download 50447.patch

Bug Description: All agreement status messages start with "Error (##)" followed
by a text string. Even success states start with "Error", and
this is confusing.

             Instead use new keywords:  Good, Warning, Bad
             Also add new attributers to display the status in a JSON format
             for easier parsing for applications:
                 replicaLastUpdateStatusJSON
                 replicaLastInitStatusJSON

Design Doc: https://www.port389.org/docs/389ds/design/repl-agmt-status-design.html

https://pagure.io/389-ds-base/issue/49602

Minor nitpick, if you have time can we use snprintf rather than PR_snprintf? No issue if you don't want to change.

As discussed, 8601 timestamps may be better (I think access log does them?)

And finally, good maybe better as "operational" or "green" etc. Email has more. Otherwise looks good!

Ahh one more point - when we update the json field moving between healthy -> warning/error, we should write to the error log at the same time, and if we move from warning/error -> healthy, we should log that too (but subsequent "healthy" messages shuold not be logged ...).

This could be a future addition though, but it would help gss diagnose issues in retrospect rather than relying on monitoring the attribute.

As discussed, 8601 timestamps may be better (I think access log does them?)

I added the ISO 8601 timestamp already - is this not what you wanted? I'm confused

And finally, good maybe better as "operational" or "green" etc. Email has more. Otherwise looks good!

This is getting silly about the names. Perhaps this ticket should be pushed out to 1.4.2 as its going to miss the deadline anyway (today) --> which means once again we missed ALL the rfe's for the next release.

I did just say pick one and be done ... :(

As discussed, 8601 timestamps may be better (I think access log does them?)

I added the ISO 8601 timestamp already - is this not what you wanted? I'm confused

Maybe I misinterpreted this becausu in your email you said you wourd remove them?

As discussed, 8601 timestamps may be better (I think access log does them?)
I added the ISO 8601 timestamp already - is this not what you wanted? I'm confused

Maybe I misinterpreted this becausu in your email you said you wourd remove them?

Well I looked into it and it was trivial - so I added it and updated the design doc.

I'm really sorry about this. I should have check the code more carefully, and I'm really sorry for the miscommunication. I'd say in the future I should do better in my review to check this, we should have kept the communication to a single source (maybe just the pr), and that it's also a good idea to comment the code to address comments that were made in the code.

Sorry this was delayed, :(

rebased onto de38d2eb4bd1cdc2ca9cfd09bd7e8cb8a23c9c85

rebased onto 35f5d6db6517bc8a64f34c994b21888f5f3254dc

rebased onto b4b1df6eb8ae12c0c8ca091fdc44d63d65998eab

ack - thanks so much for your patience

rebased onto bd80a4f531e8e42740166630855c192698a28bdc

Pull-Request has been merged by mreynolds

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This pull request has been cloned to Github as issue and is available here:
- https://github.com/389ds/389-ds-base/issues/3505

If you want to continue to work on the PR, please navigate to the github issue,
download the patch from the attachments and file a new pull request.

Thank you for understanding. We apologize for all inconvenience.

Pull-Request has been closed by spichugi
Metadata
None
No Tags
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.