You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
In the UI there is a pagination mechanism, but it is applied locally in the UI not server side.
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:
The text was updated successfully, but these errors were encountered: