+++ This bug was initially created as a clone of Bug #1414691 +++
Description of problem:
When create pvc from storage page on web console, if input pvc name containing "." such as "pvc.test", it will prompt error info:"Claim names may only contain lower-case letters, numbers, and dashes. They may not start or end with a dash. Max length of 253.", but pvc with name "pvc.test" can be created successfully in cli.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Create pvc with name containing "." such as "pvc.test" from storage page on web console.
2.Create pvc with name containing "." in cli.
$ cat pvc-one.json
"accessModes": [ "ReadWriteOnce" ],
$ oc create -f pvc-one.json
persistentvolumeclaim "pvc.test" created
$ oc get pvc
NAME STATUS VOLUME CAPACITY ACCESSMODES AGE
pvc.test Pending 6s
1.Could not create pvc.test on web console.
2.Could create pvc.test in cli successfully.
1,2.Should have consistent validation about pvc name from web console and cli.
Creating other resources have same issue, too. eg: route.
Discussed with Jordan and Routes should not be as permissive as they are, they should not be allowing '.' in the name. This bug is to track just the Route portion of the original bug that was opened.
Wait... shouldn't the object validator reject them if . is invalid? Otherwise people can still make bad routes by uploading them to the API endpoint.
And what do we do with any existing routes that have "bad" names?
That is why I cloned this bug to you guys :) the API validator is being too permissive. Jordan suggested updating it so it prevents '.' during create, but it needs to allow it during update so that existing route objects can still validate.
Why are routes with a . in the name bad? Who cares?
route name is used as a part of one segment of the generated host. in order for the router to be able to have a wildcard cert that is valid for all the default hostnames, the variable parts of the generated host (route and namespace name) cannot contain dots. otherwise, an extra segment is added to the hostname, which a wildcard cert will not match.
Dumb question: what does this have to do with networking? This is a PVC claim with a bad name.
The original report was about PVC. They decided routes were too permissive as well. I'm not sure I'm convinced. But this is about routes.
generated route name
route-name can be up to 253 characters
namespace can be up to 253 characters
we insert a "-"
everything before (or between) the "." must not be greater than 63 characters. The suffix must be less than 253 characters (limit of full path name).
What are the rules we need to apply to generate the route name?
seems to suggest that the default <suffix> is:
Setting a custom default routing subdomain (suffix):
This doesn't tell what is used when this is omitted or set to "".
Since the full path name must be 253 characters or less, and the supplied suffix is not limited (at least according to the doc), there may not be 63 characters left for the generated host name.
Per Clayton: "When we autogenerate a hostname for "foo.bar" we should turn it into "foo-bar"."
So we will continue to allow . in route names. But we will just make that transformation when we create the hostname.
Commit pushed to master at https://github.com/openshift/origin
Change "." to "-" in generated hostnames for routes
if a route is named example.test the default generated hostname is
This changes the default generated hostname to
Verified this bug on openshift v22.214.171.124
1. oc expose svc service-unsecure -n z1 --name=test1.test
2. oc create route edge edge.test --service=service-unsecure -n z1
3. oc create route passthrough pass.test --service=service-unsecure -n z1
4. oc create route reencrypt reen.test --service=service-unsecure -n z1 --dest-ca-cert=ca.pem
5. oc get route -n z1
# oc get route -n z1
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD
edge.test edge-test-z1.0224-0m7.qe.rhcloud.com service-unsecure http edge None
pass.test pass-test-z1.0224-0m7.qe.rhcloud.com service-unsecure http passthrough None
reen.test reen-test-z1.0224-0m7.qe.rhcloud.com service-unsecure http reencrypt None
test1.test test1-test-z1.0224-0m7.qe.rhcloud.com service-unsecure http None
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.