Uppercase letters in service names result in Docker API errors

[aanand]

We allow uppercase letters in service names, but Docker doesn't allow them in image names.

When you use build, the name of the image we create is based on the service name. If it contains uppercase letters, Docker will refuse to create it.

Some options:

1. Don't allow uppercase letters in service names. Nice and strict, but backwards-incompatible.
2. Do allow them, but convert to lowercase when generating an image name. This will break in the extremely unlikely scenario that two services have the same name with different case. We could check for and forbid that case if we felt like it.
3. Wait for images to be searchable by label, use labels for images (which we're going to do anyway, see Use labels to identify images instead of name convention #1403), and stop naming images based on the service name altogether.

But we've got to name them something, and it would be quite unhelpful not to incorporate the service name - right now it's nice that when I run docker images I can see which ones come from Compose, and what project/service they belong to.

[thaJeztah]

Perhaps you should open an issue in Docker, I think feature-freeze will be soon, so.. Also;
/cc @stevvooe @dmcgowan

[dnephin]

I think we could do option 3, but continue to name images with a lowercased version of the name by default. Conflicts shouldn't be a problem, because even if one project overrides another, the labels will still point at the right container/image (the image will just lose its tag).

[stevvooe]

I would recommend taking the hit with number 1. Case-sensitivity brings nothing but heartbreak. When it comes down to it, humaans don't really consider "foo" and "Foo" to be that different.

We did actually make the registry API case-sensitive, leaving it to the backend to "decide". Originally, it was all case-insensitive but that broke some tags.

If you're going to use a label, it should just be a unique identifier, allowing the image name and service name to not be linked. The root of the problem is that the naming domains require compatibility.

[conz27]

I like the approach number 1 as well despite the fact that it breaks backwards compatibility.

This would be particularly useful for "service discovery for docker containers via DNS" projects like tonistiigi/dnsdock where I am struggling precisely with the fact that my container had upper-case characters and the DNS query could not match it. Enforcing choice number 1 would allow for unique DNS entries for services as a pretty awesome side-effect of fixing the compose issue.

DNS protocol and all of the web rely on case-insensitive URLs. The case-insensitive model works quite well; can you imagine the implications of www.google.com != www.GOOGLE.com? It would be a nightmare from a debugging, security, and user experience perspective. Choice number 1 all the way!

[dnephin]

With #2092 we have a way to customize the image name instead of using the default service name. If the service name isn't used for the image name, we don't have a problem. When image isn't provided, we can lowercase the service name for the default name.

[stevvooe]

For reference, we've actually compiled a grammar for image names:

https://github.com/docker/distribution/blob/master/reference/reference.go#L1

This was quite an effort to satisfy everyone. Case-sensitivity and hostname compatibility were basically mutually incompatible and we went with what is familiar in URLs. (As @conz27, this choice is ultimately easier for users, sometimes).

Could compose simply normalize the case for the docker image when doing lookups? I think I said I favored option number 1 above, but number 2 would be easier on the user.

[aanand]

Thanks for the update, @stevvooe. Amazing how quickly we end up inventing mini-languages.

The case against Option 1 has weakened slightly because we're about to implement a new version of the Compose file format and can make backwards-incompatible changes, so perhaps this is a good opportunity to do so. I've added this issue to the list in #2504.

[aanand]

Worth noting: we now have the additional issue that we allow -, _ and . in service names, which can very easily make for invalid image tags. Option 1 should really say: don't allow service names which, when appended to <projectname>_, would result in an invalid image tag.

[stevvooe]

Amazing how quickly we end up inventing mini-languages.

This is a mistake commonly made by trainee falconers. Its actually a micro-format.

Worth noting: we now have the additional issue that we allow -, _ and . in service names, which can very easily make for invalid image tags. Option 1 should really say: don't allow service names which, when appended to _, would result in an invalid image tag.

I would suggest the new Compose format adopt the grammar from above. We are open to additions that are backwards compatible and reasonable. This may actually be supported.

I am going to do a quick refactor of the grammar to make it more clear.

[dnephin]

I think restricting the service name to be compatible with the image naming format is unnecessary. Since we're going to support custom names with #2092, all we really need to do is normalize the default image name for the case where they don't provide one (by removing any invalid characters and converting it to lowercase, basically option 2).

We just recently added support for "-_." in service names, it would be a shame to remove it again.

[stevvooe]

@dnephin Image names allow "-.", just fine. They disallow silly uses and insecure uses, such as "foo", "foo---_-___bar".

[dnephin]

@stevvooe understood. My argument is that the naming restrictions for images make sense for images, but don't necessary make much sense for service names, which are not purely for creating an image. They're a way to refer to a service locally.

[stevvooe]

@dnephin @aanand I've refactored the grammar quite a bit to clean it up in distribution/distribution#1239. Let me know which cases you want to support and we can see where the disconnects really are. I do understand that it would be nice to decouple the names, but if we can bring it under this grammar, it may provide some flexibility in the future.

[aanand]

@dnephin that's true, I hadn't considered that.

If we go down that route, we have a choice about whether to auto-munge the name or to raise an error if it's incompatible and make the user specify a tag. I'm leaning towards the latter at the moment, as long as we make the error sufficiently helpful.

[dnephin]

This is fixed by a combination of #2658 and #2458