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

Enable a more efficient polling of catalog #529

Open
duglin opened this issue Jun 14, 2018 · 10 comments
Open

Enable a more efficient polling of catalog #529

duglin opened this issue Jun 14, 2018 · 10 comments
Assignees

Comments

@duglin
Copy link
Contributor

duglin commented Jun 14, 2018

What do people think about supporting an ETag type of mechanism for /v2/catalog so that a broker can return "304 Not Modified" if nothing has changed since the last time the Platform queried the catalog? It would save the broker the time of regenerating the result, and it will save the platform the time of diff'ing it.

@dotchev
Copy link

dotchev commented Jun 14, 2018

Most of our brokers use a static catalog, so it is not an issue on the broker side.

It would be nice if a broker could specify the period when the platform should refresh the catalog, e.g. via Cache-Control: max-age=... response header. Then different brokers might use different intervals.

@duglin
Copy link
Contributor Author

duglin commented Jun 19, 2018

@mattmcneeney was this discussed during the call this week? Any feedback?

@pmorie
Copy link
Contributor

pmorie commented Jun 19, 2018 via email

@duglin
Copy link
Contributor Author

duglin commented Jun 19, 2018

@mattmcneeney
Copy link
Contributor

@duglin This was discussed briefly though we had low attendance on yesterday's call. @fmui mentioned that since ETags are just part of the HTTP spec, why do we have to add something to the spec? (I think - correct me if I'm wrong Florian!)

@duglin
Copy link
Contributor Author

duglin commented Jun 20, 2018

While true its part of the HTTP spec, given not everyone knows about it (as shown by Paul's comment), I suspect that unless we call it out people will not consider supporting this optional feature. So, a PR on this wouldn't require people to use it, but rather make people aware of it and explain any implications of its use. I know that some uses of OSBAPI will ping the catalog quite often, so I think highlighting this to help performance would be nice.

@mattmcneeney
Copy link
Contributor

@jberkhahn is this still something that may be of use to the svc-cat community?

@jberkhahn
Copy link
Contributor

sure

@mattmcneeney
Copy link
Contributor

@jberkhahn Cool - do you want to own opening the PR for this one? :)

@jberkhahn
Copy link
Contributor

i'll try to get around to it this week

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

No branches or pull requests

5 participants