#50323 Ticket 50291 - Add monitor tab functionality to Cockpit UI
Closed by spichugi. Opened by mreynolds.
mreynolds/389-ds-base ticket50291  into  master

Download 50323.patch

Description:

Added the backend functionality to the monitoring tab.

Also returned all dsconf errors as json objects so the UI could display friendly error messages

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

rebased onto b0530c3602097f8b46c58cc7bee8fe53cef256d6

rebased onto a18a305b715e105e1a033cce9d0914a5a20f6080

rebased onto 1ff482d33ae790b73310bafedf440ca95a29ea67

You've added the function here and in tools.jsx. But this one is unused in your code... Was it done for some future code?

In the navigation bar on the left, Database unfolds and it has suffixes bellow. Replication doesn't unfold but seems like it has the same structure (you can switch between replication suffixes).
I understand that we mostly have one replica entry on the instance but still, it looks weird... What do you think, maybe it will look more consistent if we will have the same unfolding options in the navigation bar? (for Replication - same as we have for Database now)

When I create an instance without any suffix - Monitoring tab is loading continuously so it doesn't work.

In the Logging settings we have - Maximum Log Size (in MB) = 100 - by default.
It is much more than 10000 lines (maximum that can be viewed in the UI).
Could we have paging here?
I understand that it is some amount of work (that we may postpone and create an issue for that) but I think it is necessary if we want our UI to be fully usable.

Also, please check the cockpit API for the working with files - https://cockpit-project.org/guide/149/cockpit-file.html
It has some nice features. :)

Besides that, I am really impressed!
Besides the good general usability on most of the sections, I like a lot the Replication tab's content with all of this Lag Reports, poking agreements, etc.
Great!

In the navigation bar on the left, Database unfolds and it has suffixes bellow. Replication doesn't unfold but seems like it has the same structure (you can switch between replication suffixes).
I understand that we mostly have one replica entry on the instance but still, it looks weird... What do you think, maybe it will look more consistent if we will have the same unfolding options in the navigation bar? (for Replication - same as we have for Database now)

I was going to do that, but the problem is that you can replicate random subtrees:

ou=people,o=simon.com
ou=staff, ou=employee,o=simon.com

There is no good way to link these replicated suffixes in a tree. It just becomes a list essentially, so a dropdown "list" made the most sense.

In the Logging settings we have - Maximum Log Size (in MB) = 100 - by default.
It is much more than 10000 lines (maximum that can be viewed in the UI).

Well you also don't want to load 100mb into memory. I was just "tailing the log" and not trying to use up too many resources. Typically though you would only be looking at last few lines anyway for debugging. You can also goto the terminal nav tab in Cockpit and vi the log if deeper analysis is required. But I see what you are getting at...

Could we have paging here?

Maybe, that would be nice, but right now its just a textarea so I need what option are available...

I understand that it is some amount of work (that we may postpone and create an issue for that) but I think it is necessary if we want our UI to be fully usable.

Yeah this might not be trivial, let me look into it, but we might have to push it off to "Version 2"

Also, please check the cockpit API for the working with files - https://cockpit-project.org/guide/149/cockpit-file.html
It has some nice features. :)

I will look into this! I forgot about it actually I know they have a type of file monitoring we could use use for continuously refreshing logs...

rebased onto d21a32a367ba61bb77fa99d56dc72cf26697310b

Changes made.

I did not add pagination to the log viewing. It is NOT trivial to add, and not that important IMHO. It would be nice to have, and we look into doing it, but it can wait. In the meantime I added a 50000 line option which should be plenty for most cases.

I think it will throw an exception because basedn is not specified. Check lib389/tombstone.py

Besides that, looks good. I am not sure if somebody else from our team would like to check the functionality but you have my ack.

I think it will throw an exception because basedn is not specified. Check lib389/tombstone.py

Good to know, but I actually don't use this function in the UI at this time, but I fix it up for future use.

The issue for logging refactoring:
https://pagure.io/389-ds-base/issue/50326

rebased onto ab94fc12e2dedf21c7784609600d60b9999e1ce4

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/3382

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