Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ML] Entity filter for the Notifications page #142778

Merged
merged 16 commits into from
Oct 11, 2022

Conversation

darnautov
Copy link
Contributor

@darnautov darnautov commented Oct 5, 2022

Summary

Even though it's possible to add job_id to the query string from the beginning, it wasn't obvious due to lacking of the UI filter.
This PR adds a custom control that allows selection of different ML entities.

image

What's supported

  • Allows picking entities from the current space
  • Restores filters state from the query string
  • Adds/removes OR clause on change
  • Persisted URL state

Corner cases

There is no uniqueness of entity IDs across different types, i.e. it's possible to have anomaly detection and data frame analytics jobs with the same ID, e.g. my_job. In this case, the entity picker will highlight all entities with provided ID as selected that mentioned in the query string.

Checklist

@darnautov darnautov self-assigned this Oct 5, 2022
@darnautov darnautov marked this pull request as ready for review October 6, 2022 16:27
@darnautov darnautov requested a review from a team as a code owner October 6, 2022 16:27
@elasticmachine
Copy link
Contributor

Pinging @elastic/ml-ui (:ml)

@darnautov darnautov requested review from peteharverson, jgowdyelastic and lcawl and removed request for lcawl October 6, 2022 16:27
Copy link
Member

@jgowdyelastic jgowdyelastic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested, added some minor comments, but overall LGTM

}, newQuery);
}

onChange!(newQuery);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if there is a risk onChange might be undefined, it might be safer to wrap this in a check.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is an issue with the types provided by import type { CustomComponentProps } from '@elastic/eui/src/components/search_bar/filters/custom_component_filter';. onChange is always defined in this case.

import { countBy } from 'lodash';
import { useMlApiContext } from '../../contexts/kibana';

type EntityType = 'anomaly_detector' | 'data_frame_analytics' | 'trained_models';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In other places in the notifications page inference is used.
I wonder if we're introducing confusion by using the label Trained models in this menu, even though it's probably clearer and we used Trained model everywhere else in the UI.
It's a shame the notifications use inference as the type.

Not asking for a change here, just thinking out loud.

Copy link
Contributor Author

@darnautov darnautov Oct 11, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree, it's indeed confusing. Everywhere in the UI code, I refer to this as trained models.
On the data level for the .ml-notifications* it's inference, hence I decided to keep it this way. If I'm not mistaken it's the only exception in the user-facing labels so far.

import { MlEntitySelector, MlEntitySelectorProps } from './ml_entity_selector';

/**
* Custom filter component to use with {@link EuiInMemoryTable}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this component limited to working with notifications only? If not, could it be moved to the top-level components folder?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I presume this is the only use case for this component, so I'd rather keep it as is for now.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK! We can always move it at a later date when we find another use case for it.

isLoading={isLoading}
singleSelection={!multiSelect}
selectedOptions={selectedEntities}
options={options}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Entities that had notifications, but have since been deleted, cannot be selected. Is there a way to populate it with all entities that have had notifications?

image

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that I hadn't synchronized the saved objects for the gallery_delete job here. Therefore the old saved object for this job still existed. Do you think we should be showing notifications for a deleted job in this case @jgowdyelastic ?

Copy link
Contributor Author

@darnautov darnautov Oct 11, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure it's possible, because of the space awareness. It'd require an extra API call to retrieve all unique terms for job_id from .ml-notifications*, but eventually, we won't be able to resolve what IDs are available for the user (because Kibana saved objects are already deleted).

Copy link
Member

@jgowdyelastic jgowdyelastic Oct 11, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the alternative is too tricky to implement. We'd have to check every job to see whether it does still exist.
Just to clarify what's happening here...
When a job is deleted, it happens in the background in es, Kibana does not know when the job has actually been deleted so we can't be sure when to delete the saved object.
It was decided that leaving these orphaned saved objects behind was not a problem. They are deleted on sync or when a new job arrives with the same name.

The reason gallery_delete is showing up here is because the saved object still exists.
IMO the behaviour here is ok. It's not ideal, but the alternative of checking whether a job really still exists before listing its messages would add an overhead.

@darnautov darnautov mentioned this pull request Oct 11, 2022
12 tasks
@kibana-ci
Copy link
Collaborator

💚 Build Succeeded

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id before after diff
ml 1626 1629 +3

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id before after diff
ml 3.4MB 3.4MB +3.8KB

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @darnautov

Copy link
Contributor

@peteharverson peteharverson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested latest changes and LGTM

@darnautov darnautov merged commit 1d08141 into elastic:main Oct 11, 2022
@darnautov darnautov deleted the ml-notifications-entity-selector branch October 11, 2022 15:57
@kibanamachine kibanamachine added the backport:skip This commit does not require backporting label Oct 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:skip This commit does not require backporting :ml release_note:enhancement Team:ML Team label for ML (also use :ml) v8.6.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants