React Timeline Chart and Table Component

[MelsHyrule]

Continuation of the React conversion for the timelines page. Part 1 of the page conversion can be found here #8496

This PR depends on ManageIQ/manageiq#22304 (or it's replacement ManageIQ/manageiq#22305) for optimization of the Event Streams API call.

Removed @pf3/timeline and old D3 code (https://github.com/ManageIQ/manageiq-ui-classic/blob/master/app/javascript/oldjs/miq_timeline.js) part of the update to jQuery3 #5585 (comment)

BEFORE

AFTER

Post Notes:

Useful links for timeline-chart dispatch events

• https://carbon-design-system.github.io/carbon-charts/documentation/modules/_interfaces_events_.html
• https://charts.carbondesignsystem.com/?path=/story/docs-tutorials--event-listeners
• https://charts.carbondesignsystem.com/documentation/enums/_interfaces_events_.line.html
  Line Chart scaleType
• scaleType: "labels" - will only show the values we have (ex. if we have 9 events and 1 event, it will only show 1 and 9 equidistant from each other)
• scaleType: "linear" - will show all the values including ones we dont have but on smaller cases (ie we only have 1 event) it will show decimals (note: decimals disappear when you have 1 and 5 events, anything lower renders decimals)

Removed `@pf3/timeline` in terms of `d3`

• Relevant PR Move remaining components in react-ui-components to ui-classic #7670
• we need d3, no getting around it, however the VERSION is what is interesting. It looks like patternfly and pf3/timeline depended on old versions of d3 (specifically 3.X) BUT the carbon-charts needed the newer version of d3 to work (5.X).
• To resolve this issue it looks like kavya made the alias of d3-5.X (in its own commit which made it very convenient to find 7b6f233) so that carbon-charts had their dependencies imported at the right version
• But now that pf3/timeline is gone so thats one less use of d3 v3.X
• patternfly still imports d3 v3.X tho

"patternfly@npm:~3.31.1":
  version: 3.31.2
  resolution: "patternfly@npm:3.31.2"
  dependencies:
    ...
    d3: ~3.5.17
    ...

so we will see in the yarn.lock multiple imports which i dont see any problem with, this is just the natural behavior of package imports

"d3@npm:^7.8.2":
  version: 7.8.2
  resolution: "d3@npm:7.8.2"
  dependencies:
    ...
  checksum: e7bf5918f2a97d0c0cc489d64348b323446aa824c32b65f0888846c26f80ed05dbee18a4b7c9a487b3e60d9d404e4672d169573fe63439e3e53abd5812bcd766
  languageName: node
  linkType: hard

"d3@npm:~3.5.0, d3@npm:~3.5.17":
  version: 3.5.17
  resolution: "d3@npm:3.5.17"
  checksum: 79b59275c36fa35a0af55f326bb56d65e14d71d44e96cbd05af767000af63c3ab8b3f479e2c25281afff7ba3f5858e272ded081e5d33807b005f217c4bfbd82d
  languageName: node
  linkType: hard

Next Steps:

Improve API call #8642

• Have page additionally filter content by (for example) the page's selected Host or VM/Template
• To do this we need to be able to distinguish what page the timeline is being called from

Improve Table

• Once we have the improved api call we can dynamically change the table content to better suit the page it's displaying from

Apply Reviews

• React Timeline Chart and Table Component #8562 (comment)

[MelsHyrule]

@miq-bot add-reviewer @DavidResende0
@miq-bot add-reviewer @akhilkr128
@miq-bot add-reviewer @jeffibm
@miq-bot add-reviewer @Fryguy
@miq-bot assign @jeffibm
@miq-bot add-label enhancement
cc @jrafanie @agrare

Opening this PR up for review. Any additional updates or changes I'd want to do on this i've listed under Next Steps in the description. This PR is already quite big so I think it would be good to split them off into their own PRs or make an issue and track them there.

[Fryguy]

@MelsHyrule Does this PR drop d3? I don't see the package.json nor yarn.lock changing, unless I'm misreading?

[MelsHyrule]

@Fryguy Ah i removed the referenced in the code but not in package.json, will remove now, thanks for catching that

[jrafanie]

FIXED

6. After clicking on a timeline event, it brings you to a new screen with nothing on it and going back doesn't bring you back to the timeline...

screenshot

[Fryguy]

I noticed you removed host.name - won't that make it a lot more expensive if it's returning the entire host object?

[jrafanie]

Yes, that was causing the issue 4) above. That was removed and I added issue 7) to add the proper ems_id/host_id filter[] as we're not filtering properly right now.

[jrafanie]

I was thinking of either a virtual column or something that would make it more reliable as the host.name sometimes comes back and others it doesn't from the same API request. It makes the logic needlessly complex in the UI.

Example API response without host.name:

        {
            "href": "http://localhost:3000/api/event_streams/48428",
            "id": "48428",
            "event_type": "MODIFY_URI",
            "ems_id": "2",
            "type": "EmsEvent",
            "timestamp": "2022-10-05T04:00:31Z",
            "created_on": "2022-10-05T03:29:55Z",
            "source": "IBM_POWER_HMC",
            "host_id": "1",
            "group": "configuration",
            "group_level": "detail",
            "group_name": "Configuration/Reconfiguration"
        },

and with a host.name(from the same API request):

        {
            "href": "http://localhost:3000/api/event_streams/67912",
            "id": "67912",
            "event_type": "MODIFY_URI",
            "ems_id": "2",
            "type": "EmsEvent",
            "timestamp": "2022-10-06T09:58:54Z",
            "created_on": "2022-10-06T09:28:19Z",
            "source": "IBM_POWER_HMC",
            "host_id": "7",
            "group": "configuration",
            "group_level": "detail",
            "group_name": "Configuration/Reconfiguration",
            "host": {
                "name": "porthos"
            }
        },

[jrafanie]

I've opened this PR to add virtual columns to address this problem: ManageIQ/manageiq#22398

[Fryguy]

🙌

[Fryguy]

Wish we could comment that this is only needed for @carbon/charts

[jrafanie]

7. Followup to issue 4). We're not specifying the host_id/ems_id as an API filter[] parameter based on the current screen we're on. In other words, we're showing all host and ems events for the other criteria.

Details

[----] I, [2023-02-10T17:31:22.457137 #37554:620ac]  INFO -- : Started GET "/api/event_streams?limit=5000&offset=0&expand=resources&attributes=group,group_level,group_name,id,event_type,ems_id,type,timestamp,created_on,host,source&filter[]=type=EmsEvent&filter[]=group=other&filter[]=group_level=[critical,detail,warning]&filter[]=timestamp%3E2022-10-05T04:00:00.000Z&filter[]=timestamp%3C2022-10-10T04:00:00.000Z" for ::1 at 2023-02-10 17:31:22 -0500

[miq-bot]

Checked commit MelsHyrule@bca12e3 with ruby 2.6.10, rubocop 1.28.2, haml-lint 0.35.0, and yamllint
2 files checked, 0 offenses detected
Everything looks fine. 🏆

[jrafanie]

Sent in chat:

ok, so the remaining TBD is:
1 - enable/disable timeline button for host/ems if they have no events
3 - select all instead of selecting events group/levels one by one
5 - date picker / auto adjust start/end date when the other is set (same month at least)
7 - add host_id, ems_id API filter[] based on the current screen… host_id for a host screen, ems_id for ems screen

See above for details on each. We can fix each separately in followup PRs.

EDIT:

It's ODD that @MelsHyrule only fixes even issues.

[jrafanie]

[MelsHyrule]

Well you see @jrafanie they're a PRIME opportunity

[jrafanie]

LGTM

[Fryguy]

What happens in other screens like VM timelines? Do we also get non-vm events there? Or does that fall into the same concern about the emas_id/host_id

[jrafanie]

What happens in other screens like VM timelines? Do we also get non-vm events there? Or does that fall into the same concern about the emas_id/host_id

Yes, it's the same thing