service name invalid

[Gokul nath]

Hi,

I am getting invalid name when i create service name with dot. It is working if i use - instead of dot. (my-service is working but not my.service). I need to use dot because it is used many places in my application.

error; metadata.name: invalid value 'my.service', Details: must be a DNS 952 label (at most 24 characters, matching regex [a-z]([-a-z0-9]*[a-z0-9])?): e.g. "my-name"

for ex; 

{

    "kind": "Service",

    "apiVersion": "v1",

    "metadata": {

        "name": "my.service"

    },

    "spec": {

        "ports": [

            {

                "port": 80

            }

        ]

    }

}

Thanks

Gokul

[Michael Goodness]

You can't use periods in the metadata.name field, hence the regex in the error message. I learned that lesson the hard way myself.

[Tim Hockin]

The main rationale for not allowing dots was to stay compatible with docker links env vars and to simplify DNS.  Honestly, I forget the reason for the shorter limit, but there was a reason (on mobile so archaeology is hard).

We have an open issue to consider expanding the length to the more common 63 characters.  I don't think there has been any consideration to allowing dots - it will make DNS a little weird, but it might be OK to allow it as a user choice.

--
You received this message because you are subscribed to the Google Groups "kubernetes-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-de...@googlegroups.com.
To post to this group, send email to kuberne...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/3b90278f-46fe-426e-aa9b-2bc87ee8986e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Clayton Coleman]

I would prefer not to enable dots unless they really enable an awesome
use case. Sometime limitations help.

> https://groups.google.com/d/msgid/kubernetes-dev/CAO_Rewb224XnvjXb9dg7TCgUnHOC2k-BvERmBZg1UPtNOnoLAg%40mail.gmail.com.

[Jordan Liggitt]

a few of the downsides to allowing dots in service names would be:
- it would make dns lookups more ambiguous
- it would mean we could never also have dots in namespaces (or dns lookups would be completely ambiguous)
- it makes it impossible to have a single wildcard cert secure all services in a single namespace (certs can only wildcard a single subdomain)

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAH16ShLrhnbKi9jaiTOKrGBBN9%3D_R8brbx3Pcz1wO67wh0nghg%40mail.gmail.com.

[Brian Grant]

We should not support dots in service names, but we should definitely document this restriction better.

On Wednesday, February 17, 2016 at 7:58:08 PM UTC-8, Jordan Liggitt wrote:

a few of the downsides to allowing dots in service names would be:
- it would make dns lookups more ambiguous
- it would mean we could never also have dots in namespaces (or dns lookups would be completely ambiguous)
- it makes it impossible to have a single wildcard cert secure all services in a single namespace (certs can only wildcard a single subdomain)

On Wed, Feb 17, 2016 at 4:20 PM, Clayton Coleman wrote:

I would prefer not to enable dots unless they really enable an awesome
use case. Sometime limitations help.

On Wed, Feb 17, 2016 at 11:23 AM, 'Tim Hockin' via kubernetes-dev

[David Aronchick]

Could we do config validation on this?

--
You received this message because you are subscribed to the Google Groups "kubernetes-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-de...@googlegroups.com.
To post to this group, send email to kuberne...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/f1b0a17e-9708-4594-9e33-b94e860fb06d%40googlegroups.com.

[Brian Grant]

The error message is already pretty clear, IMO.

On Wednesday, February 17, 2016 at 8:08:23 PM UTC-8, David Aronchick wrote:

Could we do config validation on this?

[David Aronchick]

Oops - you're absolutely right. I misread the first email.

--
You received this message because you are subscribed to the Google Groups "kubernetes-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-de...@googlegroups.com.
To post to this group, send email to kuberne...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/fd83b862-2864-41c4-9631-62e20665682a%40googlegroups.com.

[Clayton Coleman]

Clear, but perhaps not optimally readable.  We have a longstanding todo to refine these some.

--
You received this message because you are subscribed to the Google Groups "kubernetes-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-de...@googlegroups.com.
To post to this group, send email to kuberne...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/fd83b862-2864-41c4-9631-62e20665682a%40googlegroups.com.

[Gokul nath]

Thanks for clarifying it. I was looking for proper syntax and got below link. Not sure it is right link or not. Here they mentioned - and . and alphanumeric can be used. That's the reason wanted to confirm once again.  

http://kubernetes.io/v1.1/docs/user-guide/identifiers.html

Thanks

Gokul

[Tim Hockin]

We actually do allow - and . in things like pod names. Service was the
odd man out (IIRC):

1) because we (I) didn't want to define what happens to env vars when
your name starts with a numeric, so we chose RFC952 instead of 1035 or
1123 (which allow leading digits). I think we can cross that bridge
now

2) because we knew DNS was coming and we didn't want to make names
ambiguous with extra dots. We already disallow dots in Namespace
names for this reason, and we can not really ever change that without
a totally different DNS schema.

It is very unfortunate that we have inconsistent rules. I really
value consistency and we blew it on this front. I wonder if we could
crank down and eventually disallow dots in names of objects? It would
be slow and painful. Or maybe we could allow a single dot. It would
make Service DNS a little more complicated, but not terribly so. It's
still a breaking change, so it has to REALLY be worthwhile, and I am
just not sure it is.

What is worse? An 18-24 month deprecation of dots in names, or some
inconsistency in the rules of names? Obviously docs should be
updated, regardless.

[Pablo Mercado]

IMHO, remove dots from all objects.
In the long term consistency should win over been "legacy compliant".

[Clayton Coleman]

I'm not in favor of adding dots to the name without a really strong
use case that blocks a significant number of important / useful
integration. Migration is expensive and breaks other integrations. I
would be in favor of longer service names since the limit is fairly
low.

> To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAO_RewZS8PzrN7Jm_rCqAdXihSnLHv4yZuumM2KBZDybMjGxdQ%40mail.gmail.com.

[Tim Hockin]

I think longer Service names is simply a matter of hands-on-keyboard time.