MGMT-13306 - Events pagination

[jgyselov]

https://issues.redhat.com/browse/MGMT-13306

Cluster events:

Host events:

Video:

events_pagination.mp4

[ammont82]

@jgyselov I'm reviewing the PR and I've found this:

• When you have all events enabled you see the number of every type of event (Info-53, Warning-17,...):
  

• But then when you select one event type, the rest of events put 0:
  

[jgyselov]

@jgyselov I'm reviewint the PR and I've found this:

• When you have all events enabled you see the number of every type of event (Info-53, Warning-17,...):
• But then when you select one event type, the rest of events put 0:

@ammont82 Yes. The numbers in the dropdown are taken directly from the API and they correspond to the number of events of each severity with the applied filters - that includes hosts, text, and severity... So if you select e.g. "Warning", the numbers next to the rest of the severities will be zero because all of them have been filtered out.

I am aware that these numbers worked differently before - maybe that was more intuitive? But we cannot get the previous behavior with the new API, so the way I see it, we have these options:

1. Keep things as they are implemented here - if you select any severity filter, you will see 0 next to the unselected ones.
2. Get rid of the numbers next to severities altogether - the Hosts filter doesn't have them, maybe we don't need them here either.

The severity counts (coming from the response headers) are also used to calculate the total number of events which is then used in the Pagination component. With the second option, there would be no need for the severity counts - and we should probably ask BE to simply send us one number (the total).

What option do you think is the better one? Or can you think of some other options?

cc @nirfarkas

[ammont82]

@jgyselov I'm reviewint the PR and I've found this:

• When you have all events enabled you see the number of every type of event (Info-53, Warning-17,...):
• But then when you select one event type, the rest of events put 0:

@ammont82 Yes. The numbers in the dropdown are taken directly from the API and they correspond to the number of events of each severity with the applied filters - that includes hosts, text, and severity... So if you select e.g. "Warning", the numbers next to the rest of the severities will be zero because all of them have been filtered out.

I am aware that these numbers worked differently before - maybe that was more intuitive? But we cannot get the previous behavior with the new API, so the way I see it, we have these options:

1. Keep things as they are implemented here - if you select any severity filter, you will see 0 next to the unselected ones.
2. Get rid of the numbers next to severities altogether - the Hosts filter doesn't have them, maybe we don't need them here either.

The severity counts (coming from the response headers) are also used to calculate the total number of events which is then used in the Pagination component. With the second option, there would be no need for the severity counts - and we should probably ask BE to simply send us one number (the total).

What option do you think is the better one? Or can you think of some other options?

cc @nirfarkas

@jgyselov I think for user maybe is confusing this implementation. I thnk the best for me is to get rid of the numbers next to severities altogether. We need @nirfarkas for UX perspective

[jkilzi]

@jgyselov I'm reviewint the PR and I've found this:

• When you have all events enabled you see the number of every type of event (Info-53, Warning-17,...):
• But then when you select one event type, the rest of events put 0:

@ammont82 Yes. The numbers in the dropdown are taken directly from the API and they correspond to the number of events of each severity with the applied filters - that includes hosts, text, and severity... So if you select e.g. "Warning", the numbers next to the rest of the severities will be zero because all of them have been filtered out.
I am aware that these numbers worked differently before - maybe that was more intuitive? But we cannot get the previous behavior with the new API, so the way I see it, we have these options:

1. Keep things as they are implemented here - if you select any severity filter, you will see 0 next to the unselected ones.
2. Get rid of the numbers next to severities altogether - the Hosts filter doesn't have them, maybe we don't need them here either.

The severity counts (coming from the response headers) are also used to calculate the total number of events which is then used in the Pagination component. With the second option, there would be no need for the severity counts - and we should probably ask BE to simply send us one number (the total).
What option do you think is the better one? Or can you think of some other options?
cc @nirfarkas

@jgyselov I think for user maybe is confusing this implementation. I thnk the best for me is to get rid of the numbers next to severities altogether. We need @nirfarkas for UX perspective

@jgyselov you mentioned that the reason we do not get the other severities is related to the way the API works. So I guess that in the current state of the implementation, if I send an API request like: GET v2/events?...&severities=warning then the API returns only the Severity-Count-Warning header (perhaps all the other Severity-Count-* headers are also there but they are zeroed) . If that's correct, maybe we could ask @danmanor to change this behavior, so we always get all the counts the way it was before?
Anyway my take on this is this implementation is already better than what we had, it mitigates the issue that froze the browser and almost crushed the BE. So from that POV what we have here is already worthy. I see the counters issue as an UX enhancement.

[danmanor]

@jgyselov @jkilzi I think that if we want to have the severity count, it makes sense to have the filtered numbers, as it represents the counts of the events on the user side. I can change it to be the total counts, and provide an additional count of the filtered evetns in order to calculate offsets. LMK what you wish to do, btw looks good!

[jgyselov]

If we wanted the behavior to be as close as possible to the way it was before, the severity counts would have to be

• total counts of events of the respective severity across all possible pages,
• with regards to the rest of the applied filters (hosts, cluster-level, message,...)
• but not taking the severities filter itself into account

And we would need to receive information about the total number of events (with the severities filter applied) on top of that.

---

Personally, I am okay with either of the three options:

1. Keep things are they are.
2. Remove the counts.
3. Change the severity counts to be as described above.

From the UI POV, these would require relatively small changes (if any) and could be done as a follow-up.

[jkilzi]

If we wanted the behavior to be as close as possible to the way it was before, the severity counts would have to be

• total counts of events of the respective severity across all possible pages,
• with regards to the rest of the applied filters (hosts, cluster-level, message,...)
• but not taking the severities filter itself into account

And we would need to receive information about the total number of events (with the severities filter applied) on top of that.

Personally, I am okay with either of the three options:

1. Keep things are they are.
2. Remove the counts.
3. Change the severity counts to be as described above.

From the UI POV, these would require relatively small changes (if any) and could be done as a follow-up.

Agreed, let's open a follow up enhancement task, detached from this epic. I think we should go with the 3rd option in the list above.