Have a more meaningful "name" in examples?

[jotak]

Hi @gorkem ,

In the examples provided here, "nodejs" is used both as app.openshift.io/runtime and as app.kubernetes.io/name . I think it can be confusing when people try to understand what exactly they should put under "name".
Having something that looks more business-related would perhaps help to remove any ambiguity. What about using names like there is in some tutorials like here : https://redhat-developer-demos.github.io/istio-tutorial/istio-tutorial/1.1.x/index.html ; that would gives "names" such as "customer", "preference", "recommendation".

What do you think?

[sspeiche]

Based on my understanding, reviewing it again and talking to a few people. I agree this is a little confusing in this example.
I would also like to know what a springboot or thorntail sample would look like with these labels. I would example it to be something like:

For SpringBoot:

app.kubernetes.io/part-of: cool-service
app.kubernetes.io/instance: cart
app.kubernetes.io/name: openjdk
app.kubernetes.io/component: frontend
app.kubernetes.io/managed-by: odo
app.kubernetes.io/version: 1.0.1
app.openshift.io/runtime: springboot
app.openshift.io/runtime-version: 2.1.6

For Thorntail:

app.kubernetes.io/part-of: cool-service
app.kubernetes.io/instance: cart
app.kubernetes.io/name: openjdk
app.kubernetes.io/component: frontend
app.kubernetes.io/managed-by: odo
app.kubernetes.io/version: 1.0.1
app.openshift.io/runtime: thorntail
app.openshift.io/runtime-version: 2.5

Perhaps we could rename runtime to something else. The other things is missing is the opendjk version in this example. Though I expect version to be the overall app or component version, not the openjdk version.

Thoughts @sbose78 @kadel @jotak christianvogt

[jotak]

I am still confused by this use of app.kubernetes.io/name. It sounds to me it should name the workload under a business perspective, not a technical one. Much like you did with part-of: cool-service, except it refers to a micro-service and not the whole application.

Eg. with the old redhat MSA helloworld ( https://github.com/redhat-helloworld-msa/helloworld-msa )
I think we would have, at minimal:

app.kubernetes.io/part-of: helloworld-msa
app.kubernetes.io/name: aloha
app.kubernetes.io/version: 1.0.1
app.kubernetes.io/managed-by: odo
app.openshift.io/runtime: vert.x
app.openshift.io/runtime-version: 3.8

The instance is IMO something that depends more on the context of the deployment. This is how I understand it from k8s doc: An application can be installed one or more times into a Kubernetes cluster and, in some cases, the same namespace.

So I could perfectly have a single instance of helloworld-msa, in which case I don't need to specify instance. But imagine I deploy several instances, one for production, another one for demo and a third one for a talk i'm giving at summit, I would have:

app.kubernetes.io/instance: aloha-prod
# or
app.kubernetes.io/instance: aloha-demo
# or 
app.kubernetes.io/instance: aloha-summit

We must read instance as its actual meaning: another instance of the same thing. Almost a clone.

And finally there's the component label. It's expected to be something like database, frontend, backend... Not sure if it's expected to be picked from a shortlist of items, or if it's open? (I don't find this label very useful, I guess one reason it exists is to associate the service with a relevant server/frontend/db icon in some dashboards?)