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

Endpoint to know if an image is already built #998

Open
jtpio opened this issue Nov 5, 2019 · 4 comments

Comments

@jtpio
Copy link

@jtpio jtpio commented Nov 5, 2019

It would be useful to have a way to know whether or not an image is available (locally or in the registry).

As a use case, we could image alternative frontends that want to prioritize one cluster over another to minimize launch times. But it could be useful for the mybinder.org federation too.

For example:

  • with the existing build endpoint and a query parameter to stop at a specific phase: build/gh/foo/awesome-repo/7cd5df?stop=built
  • with an image endpoint using the same repo spec, that would return a 404 if the image is not found: image/gh/foo/awesome-repo/7cd5df

Also there is a conversation about this on gitter: https://gitter.im/jupyterhub/binder?at=5dc1f3cde469ef4358cd0b58

@betatim

This comment has been minimized.

Copy link
Member

@betatim betatim commented Nov 6, 2019

I think this would be useful to have. Trying to think of potential downsides and the only one I can think of is that we might have to rate limit the endpoint in case the registry can't cope with so many lookups.

I'd go for the second endpoint image/<spec> that returns a 200 or 404.


For picking a BinderHub amongst many (like the federation behind mybinder.org) I think a better approach is to upgrade the redirector we run that assigns repos to clusters. Having to query N hosts is "slow" (might take a second or two) and means you have to keep a list of valid hosts to try. Which doesn't sound like a lot of work but does get annoying over time.

Having the redirector at mybinder.org assign a launch/build request to the "best" available cluster means less work in the long term for users of a federation.

@arnim

This comment has been minimized.

Copy link

@arnim arnim commented Nov 6, 2019

Could complement the strategies discussed in #jupyterhub/mybinder.org-deploy/issues/1066

@betatim

This comment has been minimized.

Copy link
Member

@betatim betatim commented Nov 18, 2019

Now the same repo should always be launched on the same cluster. This reduces the need a bit for external tools to know which cluster to send people to because the load balancer used by mybinder.org knows best where to send people.

This endpoint would still be useful for BinderHub's own UI though.

@jtpio

This comment has been minimized.

Copy link
Author

@jtpio jtpio commented Nov 18, 2019

Nice, thanks @betatim for the heads-up.

This endpoint would still be useful for BinderHub's own UI though.

Yes, and also for single-cluster BinderHub (without the federation). So a client could test whether an image exists without using the /build endpoint (which might trigger a new build).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.