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

Update _cat/indices to new, paginated _list/indices API #921

Open
amitgalitz opened this issue Oct 28, 2024 · 4 comments
Open

Update _cat/indices to new, paginated _list/indices API #921

amitgalitz opened this issue Oct 28, 2024 · 4 comments
Labels
enhancement New feature or request

Comments

@amitgalitz
Copy link
Member

amitgalitz commented Oct 28, 2024

Is your feature request related to a problem?
We should use the new _list/indices API instead of _cat/indices to better handle fetching of indices as current cat API consumes too many resources.

Issue for new _list/indices API: opensearch-project/OpenSearch#15986
issue for context on limitation of CAT api: opensearch-project/OpenSearch#15954

What solution would you like?
Changing to a paginated API means we need to potentially change our UI as well as we will either need a mechanism to make API calls to the next set of results or relay more so on our search functionality and only display a limited (1k) number of results on the frontend at a time.

Options:

Option 1: Make the changes to list/indices and we set default to 1k without implementing pagination.

Pros:

  • Quicker implementation and clusters with over 1k indices are less common
  • Users don’t usually scroll through 1k indices in drop down without search

Cons:

  • Users will only see up to 1k indices, They need to search to easily find their index if they have more then 1k but technically it also means search results will only show up to 1k results.

Option 2: Change index selection drop down to include pagination or other UI based mechanism to fetch the next page of results

Pros:

  • This means that the user has a way to view all indices through the drop down

Cons:

  • Viewing all indices through a drop down when we reach 10k+ indices might be less useful as the number of "pages" might get too high
@amitgalitz amitgalitz added enhancement New feature or request untriaged labels Oct 28, 2024
@kamingleung
Copy link

I would recommend providing a drop down that can lazy load. Specifically, it will load the next batch of data once the user scrolls to the end of first batch. @virajsanghvi, does selectable or combobox OUI components support any sort of lazy loading?

@amitgalitz
Copy link
Member Author

Additionally @virajsanghvi I see that we have an example of a combo box utilizing react-window but I am not sure if the demo JS is correct: https://oui.opensearch.org/1.17/#/forms/combo-box#virtualized

Would this solution be good to use here for the paginated _list/indices API or should we have another lazy loading solution when we reach the bottom of the list.

@virajsanghvi
Copy link

I think the combo box virtualizes by default, which is why the demo js doesn't have anything called out. Virtualization assumes you have all the options though.

It looks like the component supports async search, https://oui.opensearch.org/1.17/#/forms/combo-box#async, but that doesn't handle loading.

I don't see a component that supports this out of the box, but maybe @AMoo-Miki may know of a component or example somewhere.

@andrross
Copy link
Member

[Catch All Triage - 1, 2, 3, 4, 5]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants