Add support for 3+-part image names (like on GitLab)

[bdrian]

This PR enables the use of "longer" image names such as gitlab.com/bdrian/binderhub/prod/<generated-image-slug>. Only the lookup for possibly existing images has to be changed, because this is the only place we cannot use the full form (repo+image names together).

To allow both magical Docker Hub short names (like jupyterhub/k8s-binderhub) and regular names referring to a registry (gcr.io/project/something), this approach cuts off the first part unless the image name looks like it may come from Docker Hub -- those image names always have two parts and certain restrictions that are not all present in Docker itself:

Organization name must contain a combination of alphanumeric characters of 4-30 characters in length. Letters must be lowercase.

Your repository name must contain a combination of alphanumeric characters and may contain the special characters ., _, or -. Letters must be lowercase.

Additionally, less than two or more than 255 characters are also refused as repository names.

To be able to test this with the existing Travis setup right away, I had to single the basename derivation out; alternatively we'd have to find a publicly reachable registry that supports 3+-part image names and is not GitLab, because getting a token from GitLab's registry doesn't work yet (see #965). Local testing with "long names" in a remote registry was fine, though.

This change breaks compatibility with registries that do not operate at their domain root (something like mycompany.com/registry), but I'm not sure if that's actually used or even possible. Additional feedback is welcome.

Contributes to #965, but doesn't close it.

[betatim]

@rochaporto what do you think of this/could you give it a spin with your setup?

[betatim]

I think we should merge and take this for a test drive and see what happens.

One more thing: what should happen is someone puts in an image name/registry that violates the assumptions made in the name derivation function? Right now I'd say "stuff" happens aka undefined behaviour. Is it easy to raise a helpful error message or some such to help out the user?

[bdrian]

Hm, I agree error handling is not done well in this PR. I'll reiterate that.

I found something else I overlooked before when looking for a way to generate useful error messages: We actually already know the registry's base address in DockerRegistry.url, which also takes care of Docker Hub references. With this, we can reliably determine which part of the image prefix is the actual image name, and don't need to assume anything about its structure.

Closing this PR to rework it

[betatim]

Ok, looking forward to an improved version.

ps. you could keep this PR open, add [WIP] to the start of the title and work on it. No need to close the PR.

[kfyhn-gf]

Hi all, great work you are doing here with Binderhub! I am stuck at the issue that this PR can solve, but it has been a while since the last activity - is it still being worked on and is any input/help needed?

[betatim]

Also solved by #1269

[minrk]

Reopening this one based on reverting #1269

It's great that this one adds the necessary test coverage for various affected cases, which I missed in reviewing #1269.

What do folks think is missing from finishing up this PR? Who would like to try to finish it up?

[nichoio]

I am the successor of @bdrian at our institution. So i have to work around the same issue. I just tested this code against our GitLab registry and it works fine. Would do more testing and create a new branch/PR with this code plus test according to current master. Good idea?

Edit: I noticed that the request for a token requires "service": "container_registry" in case of our GitLab instance. I don't know if this just applies to our GitLab instance or to others as well.
Since DockerHub doesn't seem to mind the extra param, maybe append it to all token requests?!

[nichoio]

Ok, i've prepared a new PR with basically the exact same functionality:
#1283

Hope we can make this work finally! 🙂

[consideRatio]

I understand this PR as obsolete given that #1283 was merged with most content of this PR in it. Closing - thank you @bdrian and @nichoio!