Relax strict validation for service link names

[xaka]

Rancher Version: 1.0

Docker Version: 1.10.3

Steps to Reproduce:

• upgrade rancher from 0.63 to 1.0
• upgrade any of existing services

Results:

##

I had no such issues with v0.63.

[deniseschannon]

We started doing a stricter validation in GA for service link names to ensure that the name of a link would work with internal DNS. There are some backwards compatibility as we never had this kind of validation.

New validation:
1-63 characters long
Consisting only of A-Z, 0-9, and hyphen
Can't start of end with a hyphen
Can't contain 2 consecutive hyphens

We are discussing removing the validation and allow users to create any alias name knowing that internal DNS might not work as expected.

[xaka]

1-63 characters long

Is it for service name or for service + stack name together? It looks like for both because my service name is pretty short xxxx-xxxxxx-xxxxxx (and stack name is xxxx-xxxxxx-xxxxxx-xxxxxxxxxxx).

[xaka]

BTW, even though UI reports such error, service gets upgraded anyway.

[deniseschannon]

@xaka The new validation is for the service alias name.

links:
  mysql:<validation on this name>

Nothing significant changed on the service/stack name validation.

[kaos]

@deniseschannon from the schema, I don't see the extra restrictions regarding starting or ending with a hyphen, or conescutive hyphens.. also, it seems like a slash is accepted.. ?

"validChars": "a-zA-Z0-9-/"

Is there some additional checks done on this particular resource that's not in the schema?

[kaos]

Btw, is the schema configurable on any level, or is it hardwired into compiled code?
Was hoping to be able to patch the validChars until 1.0.1 is out, as this is halting our progress.

EDIT: nvm, found this: rancher/cattle@a583888

[antmanler]

ditto,
"do not allow dots" causes lots of problems for our online services...

@kaos it's dangerous, but you can manually update the service name in service_consume_map in MySQL

[kaos]

@antmanler Thanks, but that won't work for me, unless I misunderstood you. I need to change the schema so it works for new services right away, as we deploy new stacks dozens of times a day (and delete about as many, too). So I can't run around patch each individual service.. ;)

[sangeethah]

Tested with rancher server version - V1.0.1-rc1.

Allowed to have the following formats in service links:
1."validChars": "a-zA-Z0-9-._"
2. Cannot start or end with a "-" or "."
3. Cannot contain "--" or ".."
4. Each dot-delimited label is limited to 63 chars, and the whole string to 253. If there are no dots then it is a single label and must still be <= 63 chars.

We allow service link name to start/end with _ and __ . The links are not resolvable using ping. But dig works fine. Should we restrict these as well ?

[will-chan]

we won't support begin and end _ for now.

[vincent99]

_ isn't allowed by the spec at all, so there is no point in us making up arbitrary validation rules to restrict the behavior of it. And it works fine for me:

root@aff668fb0db6:/# dig +short _under1
10.42.208.162
root@aff668fb0db6:/# dig +short __under2
10.42.208.162
root@aff668fb0db6:/# dig +short under3_
10.42.208.162
root@aff668fb0db6:/# dig +short under4__
10.42.208.162
root@aff668fb0db6:/# dig +short _under5_
10.42.208.162
root@aff668fb0db6:/# dig +short __under6__
10.42.208.162

[sangeethah]

@vincent99 , dig works , but ping failed with error "unknown host"