kubernetes/linting: Enforce naming conventions for objects

[bradrydzewski]

This is something we need to put more thought into, but basically the problem is that Kubernetes objects have the following naming restrictions:

By convention, the names of Kubernetes resources should be up to maximum length of 253 characters and consist of lower case alphanumeric characters, -, and ., but certain resources have more specific restrictions.

Drone does not enforce any naming restrictions. This prevents us from being able to use user-friendly names for Kubernetes objects. Instead we have to resort to random strings. So we either need to force (or even adopt) Kubernetes naming conventions (here in the linter) or we need to modify the kubernetes runtime to normalize names to conform to kubernetes standards ...

[paulczar]

:+1: I recommend random strings ( or something descriptive like stage number in the pipeline ) with the use of metadata/lables to map them back to the job that ran them, in fact doing a hierarchy of labels to show ownership would help with the ability to cleanup after the tests are run, which may reduce the need to create/destroy a namespace per pipeline (which requires close to cluster-admin perms, which is a bit dangerous).

[gtaylor]

Definite +1 to labels. We'd be querying/instrumenting based on these, anyway. The pod names aren't especially useful.

[yix]

My 2 cents in favour of meaningful names:

• sorting out things with kubectl will be a pain if random strings are used for object names
• gathering stats from k8s logs will be impossible/too hard because you'll have to maintain mapping between random object names and actual payload

Kubernetes itself uses very simple approach to get autogenerated names which makes them both user friendly and keeps names unique. It uses parent object name + random string. If Drone will follow same strategy overall experience will be more seamless. Example:

deployment.apps/someapp
replicaset.apps/someapp-6c677b453b
pod/someapp-6c677b453b-tvd2x