new-project only allows lowercase dns names as project names

[liggitt]

$ openshift ex new-project MyNewProjectName
F0220 12:01:27.888377   24304 new_project.go:45] project "MyNewProjectName" is invalid: Name: invalid value 'MyNewProjectName': does not conform to lower-cased dns952

If we're going to require lowercased dns names for projects, should new-project lowercase and set the original name as a display name if it differs from the lowercased version?

@deads2k

[liggitt]

Hmm... if we normalize project names to lowercase in new-project to satisfy name validation, we need to be really careful. Namespace is not validated/normalized currently, so the following does weird things:

Fails with invalid project name:
openshift ex new-project NewProjectName --admin=foo

Creates project, namespace, and rolebinding in namespace with lowercase name:
openshift ex new-project newprojectname --admin=foo

Creates rolebinding in namespace with mixed case name:
openshift ex policy add-user admin bar -n NewProjectName

$ osc describe policybindings master -n newprojectname
Name:           master
Created:        2015-02-20 12:10:03 -0500 EST
Labels:         <none>
Last Modified:      2015-02-20 12:10:03 -0500 EST
Policy:         master
RoleBinding[admins]:     
            Role:   admin
            Users:  [foo]
            Groups: []

$ osc describe policybindings master -n NewProjectName
Name:           master
Created:        2015-02-20 12:10:12 -0500 EST
Labels:         <none>
Last Modified:      2015-02-20 12:10:12 -0500 EST
Policy:         master
RoleBinding[admin]:  
            Role:   admin
            Users:  [bar]
            Groups: []

[smarterclayton]

Ugh

[liggitt]

@derekwaynecarr do you have an opinion on namespace validation when the API processes normal commands (either requiring the namespace validate as a DNS name, and/or requiring the namespace entity to exist)

[deads2k]

To be clear, this isn't new-project. This is validation for creating any project: https://github.com/openshift/origin/blob/master/pkg/project/api/validation/validation.go#L16. I presume it's done to match the restriction requirements on namespace.

F0223 08:14:59.232918   25310 create.go:81] Namespace "BIG" is invalid: metadata.name: invalid value 'BIG': must have at most 253 characters and match regex [a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*

So we probably want to decide what to do about illegal namespaces on the command line. Errors?

[liggitt]

Let the validation and errors happen server-side. Looks like namespace validation needs to change globally upstream, which will be exciting, I'm sure

[liggitt]

The only namespace validation I could see doing client-side is preventing . and .., since that can mess up the actual URI of the request sent to the server.

[deads2k]

Ah, kapi.ValidNamespace, doesn't do what you'd think it should do: https://github.com/GoogleCloudPlatform/kubernetes/blob/master/pkg/api/context.go#L77.

[liggitt]

@derekwaynecarr was it intentional that project name validation is more strict than namespace name validation? Looks like projects use IsDNS952Label and namespaces use IsDNSSubdomain, which is less strict (allows leading digit, or internal periods, I think).

[liggitt]

A lot of the weird issues around #1080 (comment) and mixed-case namespaces would go away if all our objects used ValidateObjectMeta... that ensures consistency with lower-case namespaces.

[smarterclayton]

Yeah, we need to do that soon. Was hoping we could cut over to generic etcd in one swell foop.

On Feb 23, 2015, at 6:56 PM, Jordan Liggitt notifications@github.com wrote:

A lot of the weird issues around #1080 (comment) and mixed-case namespaces would go away if all our objects used ValidateObjectMeta... that ensures consistency with lower-case namespaces.

—
Reply to this email directly or view it on GitHub.

[derekwaynecarr]

It should not be more restrictive. Will review this.

Sent from my iPhone

On Feb 23, 2015, at 9:46 PM, Jordan Liggitt notifications@github.com wrote:

@derekwaynecarr was it intentional that project name validation is more strict than namespace name validation? Looks like projects use IsDNS952Label and namespaces use IsDNSSubdomain, which is less strict (allows leading digit, or internal periods, I think).

—
Reply to this email directly or view it on GitHub.

[liggitt]

fixed in #1174