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

Add filtering on list requests (for but not limited to transit API) #24046

Open
outscale-fba opened this issue Nov 7, 2023 · 1 comment
Open

Comments

@outscale-fba
Copy link

Using the list request of the transit API always returns all the keys. There's no way of limiting the amount of keys returned in the response.
This becomes an issue when the number of keys increases : responses are getting fat and the request takes more and more time to get processed. Vault should have a way to limit the response size and processing time for this operation.

A natural solution to this would be introducing a pagination mechanism (#10887). However this looks hard to achieve because the storage system works in a "one-shot" mode (see discussion in #21164).
This ticket suggest another approach : introduce a filter parameter in the list request. This would allow limiting the amount of results in the backend, and may be easier to integrate in the "one-shot" mode of the storage subsystem (the operation still run one-shot with a filter).
Using filtering you can do a kind of simple pagination by requesting all objects starting with "a*", then all starting with "b*", etc. You don't get a strong warranty on the amount of returned results, but this is effective in reducing the amount of data returned and make the list operation useable on huge datasets.
Of course this only works if you have an id or text field on which you can apply the filter (which is the case for key IDs on the transit API)

Adding a filter capability also makes sense just for getting a subset of the keys (for transit API, but can of course be extended to others APIs).

Why this matters ?
The list operation may be very important for some usages. When managing keys the user may keep the list of keys identifiers in a separated software/database (for example to add some metadata on each key). As the amount of keys grows, there is a need to do consistency checks between the vault content and others storages having key related data. The list operation allows to do this, and it needs to do this in reasonable time / size response.

Complements:

@hellobontempo
Copy link
Contributor

@outscale-fba - Thank you for opening this issue. I've added it to our internal ticket tracking this work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants