#49599 Sync replication total init status format with update status format
Closed: wontfix 6 years ago Opened 6 years ago by mreynolds.

Issue Description

Some time ago the agmt update status was changed to a more consistent format where the messages start with the error code clearly defined:

"Error (%d) message..."

For total init status its just a error code number:

"%d message..."

The total init status should be in the same format as the update status messages.


Metadata Update from @mreynolds:
- Custom field component adjusted to Replication
- Custom field origin adjusted to Dev
- Custom field reviewstatus adjusted to review
- Custom field type adjusted to enhancement
- Custom field version adjusted to None

6 years ago

Looks good, and its good that the format is consistent, I just wonder if we should not deviate in one case:
we now have status like

"Error (0) Replication session successful"

which is a bit contradictory.

Repl update status messages also return "Error (0)" for success. In my opinion, just like in the access log, error zero is success. I don't think that's too much to ask of an admin to interpret it that way. I can file a doc bug to get this correctly documented.

So previously we just logged:

"0 Replication session successful"

Or when an error occurs:

"3 Replication halted"

I find these messages ambiguous and confusing. Clarifying what the "number" means is a big improvement, even if "Error (0)" might be confusing as it's not an error.

From my standpoint, working on the new UI, I want a consistent way to parse the status message and know if an error occurred or not. If it really is a problem using "Error(0)" for success then we need to change the replication update success status message as well, but that change has been in the code base for many releases now - which makes that change risky in my opinion.

It was just a question, so lets wait until someone complains

Metadata Update from @lkrispen:
- Custom field reviewstatus adjusted to ack (was: review)

6 years ago

It was just a question,

Of course :-) Sorry I hope I didn't come off too defensive - I was just trying to explain my train of thought on the change.

so lets wait until someone complains

I think IPA complained about it when I changed the update messages to always start with "Error(x)". So to remove it again would cause complaints from them I would think.

Since I got your ack, I will open a doc bug next. Thanks!

Filed doc bug for DS 11:

https://bugzilla.redhat.com/show_bug.cgi?id=1554422

02a8def..b67f0f8 master -> master

Should this be backported to 1.3.7? Will discuss that in next team meeting...

Should this be backported to 1.3.7? Will discuss that in next team meeting...

Looking through IPA's code this change would not impact them.

Metadata Update from @mreynolds:
- Issue set to the milestone: 0.0 NEEDS_TRIAGE (was: 1.4.0)

6 years ago

I would support backporting because I'm always pro-admin facing usability improvements :)

Reviewing this patch, I would say that the messages help a bit, but we need to explain where to find what each err code means. Today if you see:

"Error (-6879) replication failed".

What does that mean? Where am I meant to look? What am I meant to do?

Error messages should clearly communicate:

  • what went wrong
  • why it went wrong
  • possible resolution steps

So for example a better message is:

"Error: (-6879) replication failed. This is likely due to the remote server being offline or network communication interupted. Check the connection to <hostname> and ensure the port is operating".

For example.

So it means you have to do more work to actually present meaningful content to the user, but it strongly helps an admin to resolve the issue at hand. It may expand the size of the patch however ;)

The error messages can be improved for sure. This ticket was just to make the total init status message format the same as the update status message format. We should file a new ticket for improving the actual messages/content for these two status'.

Great, lets do that before we forget then :)

we have a doc for the update status here:
http://directory.fedoraproject.org/docs/389ds/FAQ/replication-update-status.html

and Marc has also added it to the official docs

Metadata Update from @mreynolds:
- Issue set to the milestone: 1.3.7.0 (was: 0.0 NEEDS_TRIAGE)

6 years ago

81a9d75..485cf0c 389-ds-base-1.3.7 -> 389-ds-base-1.3.7

Metadata Update from @mreynolds:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

6 years ago

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 issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/2658

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: fixed)

3 years ago

Login to comment on this ticket.

Metadata