Endpoint to know if an image is already built

[jtpio]

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]

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]

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

[betatim]

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]

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).