Api for timeline charts.

[kavyanekkalapu]

We have to convert existing pf charts to carbon. carbon doesn't have form elements like pf chart. But, we can create those using carbon react components and based on form results when apply clicked, we can display chart.

EDIT:

Adding task items:

• core: Add timeline_options to expose event_streams OPTIONS to the API manageiq#21552
• core fix: Fix group level and names for miq event manageiq#21569
  • followup - Fix (or add?) i18n to the backend or on the API side: @jrafanie.
• api: Expose MiqEvent/EmsEvent group/levels in event stream OPTIONS #1099
• Test that you can filter event_streams based on group_names/group_levels which are different for each EventStream subclass. For example, group names such as ems_operation/host_operations/compliance (MiqEvent) in addition to the EmsEvent ones: addition/configuration/console. Same for group levels: sucess/failure (MiqEvent) and critical/detail/warning (EmsEvent). EDIT: Works: see Api for timeline charts.  #1090 (comment)
• Add subcollection support for events streams in the primary collections that have it as an association.

[kavyanekkalapu]

cc @Fryguy

[kavyanekkalapu]

@miq-bot assign @Fryguy

[Fryguy]

So, as discussed, we should drop the Timelines tab from the server diagnostics as those are redundant with just navigating to the server's VM and looking at the timelines there. This is in ManageIQ/manageiq-ui-classic#7940

---

For the upper portion, the dropdown data comes from EventStream.events_groups and EventStream::GROUP_LEVELS, so we need to expose that over the API.

I think the tricky part is that while we have the EventStream.group_and_level method that was built for lookup purposes (to handle regexes, for example), the UI built their own lookup stuff in app/controllers/application_controller/timelines/options.rb. An event has a virtual column for the group, so that may be sufficient, if the event record from the API is queried. However, we may want some options for the events API to filter by group and level, where we can do the work on the API side to filter them out.

[Fryguy]

Discussed a bit with @jrafanie...

---

For the dropdowns, something like this would be expected

OPTIONS /api/event_streams

{
  "EmsEvent": {
    "description": "Management Events",
    "group_names": {
      vm_operation: "Vm Operations",
      ...
    },
    "group_levels": {
      critical: "Critical",
      ...
    } 
  },
  "MiqEvent": {
    "description": "Policy Events",
    "group_names": {}
    "group_levels": {
      success: "Success",
      failure: "Failure"
    } 
...

The MiqEvent group names are MiqEventDefinitionSet.pluck(:name, :description).to_h, and the EmsEvent group names are already available in EventStream.event_groups.

We should create a consistent interface at the model level of each of these (and perhaps all of the other subclasses of EmsEvent as a follow up) that can return this group and level information. Then the API can roughly do EmsEvent.subclasses.map { |c| [c.name, c.group_and_level_details] }.to_h

---

For the querying we already have the event_streams endpoint, and it can filter on group_level, group_name, timestamp, etc. For example:

/api/event_streams?expand=resources&attributes=group,group_level,group_name&filter[]=host_id=25&filter[]=group_level=critical

We may want to have event stream as a subcollection on host and vms if they are not there already.

---

One other small feature is that the calendar shown defaults its value to the "last event" timestamp that was collected (via the method first_and_last_event. However, considering we are planning to change that date portion of the timelines UI, I'm not certain we need that anymore. If we do it can be added as a follow up somehow.

[jrafanie]

Test that you can filter event_streams based on group_names/group_levels which are different for each EventStream subclass. For example, group names such as ems_operation/host_operations/compliance (MiqEvent) in addition to the EmsEvent ones: addition/configuration/console. Same for group levels: sucess/failure (MiqEvent) and critical/detail/warning (EmsEvent).

This works: http://localhost:3000/api/event_streams?expand=resources&attributes=group,group_level,group_name,id,event_type,message,ems_id,type&filter[]=group_level=critical&filter[]=or%20group_level=detail&limit=5000&offset=3000

(ignore the limit/offset, that's what I needed to get the correct records to come back in my test)

RESPONSE:

{
    "name": "event_streams",
    "count": 3770,
    "subcount": 770,
    "subquery_count": 3770,
    "pages": 4,
    "resources": [
        {
            "href": "http://localhost:3000/api/event_streams/6420780",
            "id": "6420780",
            "event_type": "request_starting",
            "message": null,
            "ems_id": null,
            "type": "RequestEvent",
            "group": "other",
            "group_level": "detail",
            "group_name": "Other"
        },
...
        {
            "href": "http://localhost:3000/api/event_streams/8534148",
            "id": "8534148",
            "event_type": "HOST_AVAILABLE_UPDATES_FAILED",
            "message": "Failed to check for available updates on host dell-r420-05 with message 'Failed to run check-update of host '10.8.96.15'.'.",
            "ems_id": "56",
            "type": "EmsEvent",
            "group": "other",
            "group_level": "detail",
            "group_name": "Other"
        },
        {
            "href": "http://localhost:3000/api/event_streams/8534149",
            "id": "8534149",
            "event_type": "VmCreatedEvent",
            "message": "Failed to check for available updates on host dell-r420-04 with message 'Failed to run check-update of host '10.8.96.14'.'.",
            "ems_id": "56",
            "type": "EmsEvent",
            "group": "addition",
            "group_level": "critical",
            "group_name": "Creation/Addition"
        }
    ],
    "actions": [
        {
            "name": "query",
            "method": "post",
            "href": "http://localhost:3000/api/event_streams"
        }
    ],
    "links": {
        "self": "http://localhost:3000/api/event_streams?expand=resources&attributes=group,group_level,group_name,id,event_type,message,ems_id,type&filter[]=group_level=critical&filter[]=or%20group_level=detail&limit=5000&offset=3000",
        "previous": "http://localhost:3000/api/event_streams?expand=resources&attributes=group,group_level,group_name,id,event_type,message,ems_id,type&filter[]=group_level=critical&filter[]=or%20group_level=detail&limit=5000&offset=2000",
        "first": "http://localhost:3000/api/event_streams?expand=resources&attributes=group,group_level,group_name,id,event_type,message,ems_id,type&filter[]=group_level=critical&filter[]=or%20group_level=detail&limit=5000&offset=0",
        "last": "http://localhost:3000/api/event_streams?expand=resources&attributes=group,group_level,group_name,id,event_type,message,ems_id,type&filter[]=group_level=critical&filter[]=or%20group_level=detail&limit=5000&offset=3000"
    }
}

[miq-bot]

This issue has been automatically marked as stale because it has not been updated for at least 3 months.

If you can still reproduce this issue on the current release or on master, please reply with all of the information you have about it in order to keep the issue open.

Thank you for all your contributions! More information about the ManageIQ triage process can be found in the triage process documentation.

[miq-bot]

This issue has been automatically closed because it has not been updated for at least 3 months.

Feel free to reopen this issue if this issue is still valid.

Thank you for all your contributions! More information about the ManageIQ triage process can be found in the triage process documentation.