What are valid name values?

[kadel]

Currently the components.container.enpoinds.name is defined as an ordinary string without any additional restrictions.
I'm not sure that this is what we want.
This field also serves as a unique identifier for referencing this field in other places (like in plugins or parents).
Shouldn't there be some restriction name value?
I'm not sure if we want people to create an endpoint with names like my super awesome endpoint.

This is not just for endpoints, but also for any other name or id field. We probably should put more restrictions on the name fields.

[kadel]

I'm proposing to restrict names, ids or any other filed that is used for identification to 63 characters, begin and end with an alphanumeric character ([a-z0-9A-Z]), dashes (-), dots (.), and alphanumerics between.
([a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*)
This will ensure that the values can be used as a Kubernetes resource name or as label values.

[maysunfaisal]

Odo currently does this during its internal validation. Not sure about the endpoint name but Odo validates component names as we need a valid name for container/volumes. Having said that, this should be present in general validation when a devfile is being parsed and could probably be defined in the work done by #151

[elsony]

Discussed and decided to add the naming restriction as specified in #201 (comment). One thing to note is that we are not trying to limit devfile definition to be used in the context of Kubernetes only by adding the same rules as the Kubernetes resource name and labels. By adding this restriction, we are just making the tools to be able implement the devfile features more easily in a Kubernetes environment which is one of the main use case for devfile. With this more restricted rule, it should still work in other environments, e.g. local docker.

[yangcao77]

We might want to treat Id and Name with different rules. Id can be case sensitive, since it's not being used as resource name in neither Kube/Docker; but Name need to fall with more restrictive rule to be able to work for both Kube and Docker.

This also involves how parser, validator and consumers going to behave.
Here is our proposed rule:

• id can be case sensitive i.e.; commands run and RUN are different because these are not Kube/Docker representation but devfile representatin
• name should be case insensitive i.e.; component tools and Tools are the same because Kube requires it to be lowercase and that works for both Kube and Docker
• validation will only validate name i.e.; it has to small case and less than 63 chars because of Kube requirement
• parser should not do any conversion of name/id because parser responsibility is to parse what is in the devfile and return it and also accept what the tools want to write and write to the devfile. It just reads and writes data that is given, no processing on the data.
• all consumers should follow the same rule to be consistent

[yangcao77]

Discussed and decided to have Id and Name share with same rule (#201 (comment))

• limit to lower case chars, i.e. no upper case allowed

• limit within 63 chars

• no special chars allowed, only dot(.) and dash(-)

• start with an alphanumeric character

• end with an alphanumeric character

The validation will be done as part of schema validation, the rule will be introduced in schema definition, any objection of the rule in devfile will result in a failure.

EDIT: removed the dot, as Maysun mention in #201 (comment) that dot is not valid being used in K8 resources names

[maysunfaisal]

Another alternative to baking in the regex to the schema, is to use the validation provided by kubernetes -> https://pkg.go.dev/github.com/kubernetes/apimachinery@v0.0.0-20191004074956-c5d2f014d689/pkg/util/validation#IsDNS1123Label

Odo currently uses this to validate some of the names/id. Advantage of this way is we dont have to maintain the regex on our schema. Disadvantage is you will need to call devfile validation to have the field validated.

EDIT - also the name cannot have a . because Kubernetes uses the DNS Name convention linked above. Here is the err I get:

unable to create Deployment myj: Deployment.apps "myj" is invalid: spec.template.spec.containers[0].name: Invalid value: "tools.1": a DNS-1123 label must consist of lower case alphanumeric characters or '-', and must start and end with an alphanumeric character (e.g. 'my-name',  or '123-abc', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?')

[yangcao77]

EDIT - also the name cannot have a . because Kubernetes uses the DNS Name convention linked above. Here is the err I get:

unable to create Deployment myj: Deployment.apps "myj" is invalid: spec.template.spec.containers[0].name: Invalid value: "tools.1": a DNS-1123 label must consist of lower case alphanumeric characters or '-', and must start and end with an alphanumeric character (e.g. 'my-name', or '123-abc', regex used for validation is 'a-z0-9?')

Nice findout Maysun. (([a-z0-9]([-a-z0-9]*[a-z0-9])?)*) should be the regex being used then