[Search] Background session management UI

[lizozom]

Part of #61738

The Background Session feature requires a new management section under Stack Management, to manage background sessions.

The list should show a table of the current user's sessions:

• Name
• Icon indicating the app that created the session
• Creation time
• Status (Running, finished, expired, etc.)
• Actions

It should be sorted by creation time descending by default.
The list should support searching, filtering and sorting as other management views do.

If there are running sessions, the list should re-fetch data periodically. I would use the snapshot restore view as reference for this behavior.

Each row should support the following actions:

• Navigate back to app
• Cancel (expire) a running background session
• Extend the expiration of a background session

Note: The Session objects will be hidden, requiring some special handling.

[elasticmachine]

Pinging @elastic/kibana-app-arch (Team:AppArch)

[tsullivan]

Hi, I'd like to get started on this task. I am going to assign it to myself and begin to work on making the POC for this UI.

As I understand, completion of this task is dependent on new server-side API(s) in Kibana for Background session. I'll have to keep track of that progress so that when the time is right, the POC for the UI can switch over to using real APIs.

[tsullivan]

A few questions about the UI:

• What Types are available in the drop down? Are the types showing anywhere in the table?
• What does the View button do?
• How do you extend the expiration?
• Does the search box work on every column, or just the "Request Name" column?
• Does checking the checkbox next to "Request Name" show a delete button? Or something more?

Edit: one more:

• can users only see the background searches they have created (when security is enabled)? If a user has "superuser" privileges, can they see all background searches?

[legrego]

The list should show a table of the current user's sessions

@thomheymann and I were discussing a related topic today: managing your own API Keys. While it's an administrative function, it's not really a "Stack Management" function. Managing your own background sessions almost feels like it belongs as part of the "Account Management" screen.

The Account Management screen isn't currently pluggable, but we can change that if you agree that it makes sense there. I don't want to force an implementation one way or another, I'm just providing a drive-by comment for your consideration 😄

I assume that background sessions are designed to work even when security is disabled, so in that case, you wouldn't have an account management screen to hook into. So perhaps stack management is the next-best place to add this. We can always cross-link from account management to make it discoverable from there if we think it'd be helpful.

tl;dr what you're planning is probably the right way to go

[tsullivan]

Thanks for your inputs @legrego. Reporting is in the same boat as this feature then, which is a little more familiar to me. Reporting works with security disabled, which could be the reason why the Management UI is linked from Stack Management.

I have thought if Kibana has a "notification center" then it could be handy as a way to get to the management UI, since when status changes in a background search, the user may like seeing a notification about it, in a central UI for all Kibana notifications.

[lizozom]

@tsullivan

What Types are available in the drop down? Are the types showing anywhere in the table?

The types are Discover, Dashboard or any other app that integrates and creates sessions. Those types are reflected in the icon next to each line, reflecting the app that created it.

What does the View button do?

The Session object has a url field, taking the user to the exact configuration that created the session. Clicking on the View action should navigate to that URL. This action should be available for all Session statuses. (But if the session is Expired it will trigger a new session to be created upon arrival.)

How do you extend the expiration?

It's one of the APIs we need to define in the API task. It's done by posting a request to the async search API with the search ID and a new keepAlive value.

Does the search box work on every column, or just the "Request Name" column?

I think it should be consistent with other management table views. I suspect it's just the name field.

Does checking the checkbox next to "Request Name" show a delete button? Or something more?

I don't think we need to support bulk operations at the moment, so no need for the checkbox at all. The 'Cancel' action you see in the mock will cancel the running search and move the saved object into a Canceled status.

can users only see the background searches they have created (when security is enabled)? If a user has "superuser" privileges, can they see all background searches?

At the moment, it seems like users will be able to see only their searches. The search API doesn't support admins applying any changes to other user's searches. Instead, we'll have to implement a management view using the Tasks API. I guess it can be implemented inside this view or as a separate management view that applies not only to BGS but to other things like Runtime fields.

Let me know if there are any additional questions! 🚀

[tsullivan]

cc @mdefazio

Thanks Liza! Very helpful.

Clicking on the View action should navigate to that URL.

I forgot to ask, but does the same thing happen if you click on the Request Name links?

It's one of the APIs we need to define in the API task. It's done by posting a request to the async search API with the search ID and a new keepAlive value.

As far as how to do it through the UI though, would there be an Extend button under Actions next to View and Cancel ?

At the moment, it seems like users will be able to see only their searches.

++ this is how Reporting works. There's a created_by field in the document object. When security is disabled, the field is false (but I'm not sure why we didn't go with null).

[mdefazio]

@tsullivan Here are responses to your questions:

I forgot to ask, but does the same thing happen if you click on the Request Name links?

Yes, clicking the name would also direct you to that URL

As far as how to do it through the UI though, would there be an Extend button under Actions next to View and Cancel ?

Yes, there would be an option in the row's overflow menu to Extend.

I've updated this whimsical doc with a screenshot and corrected filters/status/actions. I'm happy to connect this week if you have additional questions. This management view was created awhile ago, so it could possibly benefit from a fresh look.

[tsullivan]

@lizozom @lukasolson @mdefazio

Question:
When the user cancels a session, should the status change to "Cancelled"? If so, what color would the badge show up as and how would other things in the row look?

[mdefazio]

Am I able to restart a cancelled session? There are no other actions I can perform on this session once I cancel it, correct? I will update the mockups to include this scenario (and which badge/color should show).

[lizozom]

@mdefazio if you cancel a session or if it's expired, you can still View it.
Opening it will allow you to re-run a new session with the same configs.

[mdefazio]

Perfect, thanks

[mdefazio]

Here is an updated mockup showing the cancelled row. I've also made a few other improvements around showing the status and the columns shown. @tsullivan Please reach out with questions—I think this is still close to the preliminary mock I shared, but let me know if you have concerns.

[tsullivan]

@mdefazio looks good! It is pretty close to the preliminary mock.

A few questions about UX:

• We are leaving out bulk actions for now, so the initial PR I'm working on won't have the checkboxes per row
• We probably should show the expiration date somewhere in this table, especially for sessions where their expiration can be extended.
  • In my PR branch currently, I am showing expiration in a human friendly format for the sessions that are "expiring soon", which was in the preliminary mock. I'd like to leave those until we can explore more options for showing expiration date for all sessions.
• After looking more into the service code for Background Search, I have noticed there also is an Error status.
  • I'm not sure if we have the error message or reason available in the saved object data for the session

A few questions about EUI

• I'm using EuiInMemoryTable and I'm finding a way to "gray out" the table rows for expired or cancelled sessions
• I have not found a way to show the count of options in the dropdowns: For example: [Status (3)].

Here are some screenshots of my PR branch showing a few samples of random data, including what a possible error status item would look like, until I get a quick design for it :)

Edit: I'm just noticing now that my status columns doesn't have the status inside of an EuiBadge. That will be an easy fix

[tsullivan]

cc @elastic-jb

[mdefazio]

Hi Tim, reposting this gif here for visibility. Updated to show how we can expose the expiration date and error status. The error status would be considered cancelled with a message next to it that it cancelled due to an error. I'm curious to hear other options for this, or if this line of thinking is incorrect.

My thinking is that we do not need that many columns/information. My assumption is that we can show a message with the last status (Completed at 10:00, or Expiring in 2 days). But I don't think we need dedicated columns for start/complete/expiration time.

I've also moved the icon outside of the badge for more cosistency with other uses—would also be nice to be able to click on the badge and apply the filter.

I have not found a way to show the count of options in the dropdowns: For example: [Status (3)].

We can also just show the numActiveFilters as described here.

[lizozom]

@mdefazio I guess we could do this as a second step, but I think that rather than having a refresh button, we could re-fetch the data if there are any running sessions.

A good UI reference is what you see when restoring Kibana from a snapshot.

[mdefazio]

Sounds good. However is there a certain level of comfort for users to know they can refresh/re-fetch data when they want? I know we kind of do both ways across Kibana, so if it makes it easier and then see if anyone wants it added.

[tsullivan]

We can have the refresh button show always, and have a spinner show inside the button when they click it, and also when results are loading automatically (data automatically loads and spinner automatically spins).

Each row should support the following actions:

• Navigate back to app
• Cancel (expire) a running background session
• Extend the expiration of a background session

If it's possible, I would like to try to merge the Management app UI even if all of these capabilities aren't ready in the session client API.

The first phase has View and Delete as available actions. Once cancel and extend are ready in the session client, we can add those actions in the Management UI.

How do those 2 things sound?

[tsullivan]

To get the listing items page-by-page, we could use server-side paging, where the UI requests 10 sessions at a time. Or we could have the UI fetch all of the sessions on each refresh interval, and do in-memory paging in the table UI.

Both ideas have pros and cons:

Getting one page at a time:

• CON: makes navigating pages, sorting and filtering slower
• PRO: smaller HTTP response payloads on each refresh interval and filter action

Getting all the pages

• CON: The HTTP response payload size is arbitrarily large
• PRO: Sorting and filtering seem very fast

In the scenario where we fetch all of the sessions, we would want to run a _count query to find the number of sessions in the data, and then do a _search with the counted size to ensure that all of the sessions are in the result. Alternatively, we could have a configurable limit of sessions and always use that as the search size.

I propose that the data fetch method is:
Use a configrable limit (in kibana.yml) for the max size of sessions that can be fetched. The default is 10000. Always use that size in the fetch interval. Use in-memory table paging in the UI.

I think that proposal works well because it seems unlikely that a cluster would have more than 10000 saved background search sessions.

[elastic-jb]

I like this approach. I think the payload size is a good tradeoff for a better experience and more responsive sorting/filtering.