Add bounds on number of elements in api/v1/log/entries/retrieve

[priyawadhwa]

Currently set the limit to 10 entries, we can increase it if users request it.

It's difficult to know how much this will affect users. Based on parsing Rekor logs in the last 1 week, there are 290 requests to this endpoint that took >1s, which I'm assuming was requesting more than 10 entries (but could also just be related to something else). A lot of these logs are manual testing @var-sdk and I were doing, and there aren't any logs on the weekend. If anyone has suggestions on how to roll this out I'm happy to make changes.

closes #901

logs query

Signed-off-by: Priya Wadhwa priya@chainguard.dev

cc @var-sdk

[bobcallaway]

can you also add the limit to the various fields in openapi.yaml?

[priyawadhwa]

can you also add the limit to the various fields in openapi.yaml?

yup, added!

[codecov-commenter]

Codecov Report

Merging #1011 (14651f8) into main (568e31a) will increase coverage by 0.04%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##             main    #1011      +/-   ##
==========================================
+ Coverage   41.41%   41.45%   +0.04%     
==========================================
  Files          70       70              
  Lines        6863     6867       +4     
==========================================
+ Hits         2842     2847       +5     
  Misses       3724     3724              
+ Partials      297      296       -1     

Impacted Files	Coverage Δ
pkg/api/entries.go	0.00% <0.00%> (ø)
pkg/api/error.go	0.00% <ø> (ø)
pkg/types/rekord/v0.0.1/entry.go	48.68% <0.00%> (+0.65%)	⬆️
pkg/types/alpine/v0.0.1/entry.go	54.87% <0.00%> (+1.21%)	⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[bobcallaway]

lgtm

[var-sdk]

For rollout there are options:

1. Roll it out as dark-launch with no enforcement and add a metric to count occurrences where a caller would be hit by the limit. Turn on enforcement after gathering data for some bake period that demonstrates no "real" usage that would be broken.
2. Roll it out under a flag so the limit can be adjusted or killswitched if this causes problems for users.
3. Roll it out as is and potentially break customers. We're pre-GA so no guarantees on API stability yet.

Post GA we will need to be following some combination of 1&2 for any breaking or risky change.

[priyawadhwa]

I'm open to 2 or 3 for this change. @bobcallaway or @var-sdk, any preferences?

[dlorenc]

I think a notification period (email and slack), wait a few days, then roll it out with a potential breakage would be fine.

[priyawadhwa]

SGTM. Had to fix a merge conflict, if someone could LGTM this :)