-
Notifications
You must be signed in to change notification settings - Fork 1.1k
/api/flux/v6/images?service=<all> returns context deadline exceeded #913
Comments
If we could declare a "tagsBefore" and "tagsAfter" additionally to "tagsLimit" (mirroring the /history?params) we would have a lot flexibility in the UI to overlay image information in a timeline like manner. |
Ideal migration strategy would be to:
|
A bit of evidence for what's happening .. If I curl the API at our dev environment, I get context exceeded (i.e., a timeout). If I port-forward to the fluxd pod and curl the same API endpoint, I get a full result -- it's about 3MB. This makes me suspect one of a couple of causes:
In either case, a remedy is to reduce the amount of data sent. Currently we send O(containers x available images) items; if we summarised it to just the current image, the latest image according to filter policy, and the distance between, that would reduce it to O(containers). We would probably have to implement a shim in the service to do the summary for us if the daemon isn't new enough, but that may be good enough. |
I'm willing to make this the default mode of the new API endpoint, and adjust the output of |
Yep! That all sounds grand. Service summary shim would be nice to have but the deadline exceeded is between the service and the daemon? I think a snappy 404 + please upgrade is preferable to extending deadlines perhaps. |
If we're going to use this API for the main bit of the GUI, I'd rather not suddenly lock people out of it. I don't propose extending the timeout -- just reducing the amount of data sent over the last couple of hops back to the GUI. It may not be enough, but we'll pretty quickly see if this helps, in dev. |
For sure we want everyone to have all the cool new stuff! If we can change the service to support this new API even w/ old fluxds that would be awesome. I'd imagined that we might not be able to do that, so was planning on leaving the current UI in place for older fluxds. (+please upgrade banner). Here's hoping its enough though! Would save another ui version "fork" 👌 |
Rough implementation plan:
|
Current
Having a
To reduce data size, we could add a limit filter which is a little bit more explicit on a per field basis. The above seem to be details which can be discussed in the PR - so I will get that up. There is the case where if the client sets the limit but the summary information is not available then it can't calculate that information, but this shouldn't be the case if both were introudced in the same version. |
Not sure what you mean, @aaron7 -- do you mean that we might change how |
Oh I think I understand -- |
From in-person discussion with @squaremo : Current
We would like to add some summary information for objects under the list of
@squaremo is These will be added as extra fields and all requests will include these by default. We will however introduce a new query parameter to allow the client to only request specific fields. i.e. |
... within the container struct.
✔️ I like this approach, because it's both forward- and backward-compatible (or at least, it punts compatibility to another layer). NB we would want to return a HTTP 40x status if we don't understand any of the fields mentioned. |
We may also want the fields
since they will often (always?) be more useful than the |
Yes! Additionally it would be awesome to have
Then we'd have all the summary info for the deploy-status-table and could avoid |
The query is probably too big to lookup/encode/transmit in 10s.
Use cases:
fluxctl release --all --update-image=library/hello:v2
We need to choose a subset of the tags.
Ideal response:
/images?service=<all>&tagCreatedAt=gtCurrent
: Include all the tags where tag.CreatedAt > Current.CreatedAtSmall caveat: the ideal response might be too big sometimes? The next idealist response would be:
/images?service=<all>&tagLimit=1&onlyFilteredTags=true
: include 1 tag for each image that matches whatever tagFilter is set.The text was updated successfully, but these errors were encountered: