Recommended labels name and instance

[ametad]

Hello @stefanprodan

This choice about not using the app.kubernetes.io/instance label (described here) is somewhat confusing to me, because of the explanation about those well-known labels from the docs :

app.kubernetes.io/instance Type: Label

Example: app.kubernetes.io/instance: "mysql-abcxzy"

Used on: All Objects (typically used on workload resources).

A unique name identifying the instance of an application. To assign a non-unique name, use app.kubernetes.io/name.

One of the recommended labels.

app.kubernetes.io/managed-by Type: Label

Example: app.kubernetes.io/managed-by: "helm"

Used on: All Objects (typically used on workload resources).

The tool being used to manage the operation of an application.

One of the recommended labels.

app.kubernetes.io/name Type: Label

Example: app.kubernetes.io/name: "mysql"

Used on: All Objects (typically used on workload resources).

The name of the application.

One of the recommended labels.

app.kubernetes.io/part-of Type: Label

Example: app.kubernetes.io/part-of: "wordpress"

Used on: All Objects (typically used on workload resources).

The name of a higher-level application this object is part of.

One of the recommended labels.

Confusion

My confusion is in:

• part-of should be used for the name of the sum of all components, like in the example the "Wordpress" deployment.
• name is the name of the component, this should not be unique every time you deploy it. Like the name of a tool is what it is and therefore you know what is talked about.
• The particular instance of the component on the other hand should have a unique name.

Humble question

Would you perhaps reconsider the usage of the well-known labels and include the instance label to make a deployment unique?

[salotz]

You can customize this to suite your needs. I also had issues with the semantics of the starter blueprint and the timoni core library in terms of how I want to define applications, resources, etc.

Ultimately I think this shouldn't be something that Timoni at its core is overly prescriptive of because I'm sure there is no solution that will make everyone happy, and ultimately there is no hard and fast standard for what "applications" are in kubernetes.

[ametad]

Hi @salotz Sorry for my late response, but I appreciate your feedback.

I thought that the specific label choice is something hard coded in Timoni:

instance.timoni.sh/name: <NAME>
instance.timoni.sh/namespace: <NAMESPACE>

Source: https://github.com/stefanprodan/timoni/issues/299#issuecomment-1871807252

How would you suggest I customize this to suite me needs? This is something I don't understand as of yet.

[salotz]

@ametad I don't know about the *.timoni.sh namespace of labels, and I guess you don't have to since its in that namespace. I was only referring to the app.kubernetes.io label namespace (and perhaps your own custom namespaces), which is set if you use some of the "standard library" of components that Timoni provides as (I think) a convenience. If you don't use those then you can set these labels to whatever you like.

[ametad]

@salotz Thank you for pointing out the namespace! I completely overlooked that, I am so sorry. I feel a little stupid now... but I'm only human after all :smiling_face_with_tear:

Yes of course the app.kubernetes.io labels are the responsibility of the user of Timoni. Not of Timoni, as it has it's own namespaced labels.

And indeed we users can configure the app.kubernetes.io labels in the config of a Timoni module, as Stefan Prodan explains here:

The instance name and namespace are set automatically by Timoni's server-side apply engine to track ownership, every object has these labels in cluster:

instance.timoni.sh/name: <NAME>
instance.timoni.sh/namespace: <NAMESPACE>

Given this, I didn't want to add the Kubernetes instance label as it would be confusing.

I suggest you add the app.kubernetes.io/part-of label to your modules, this can be done in the #Config with:

#Config: {
  metadata: labels: (timoniv1.#StdLabelPartOf): "cert-manager"
}

[salotz]

It is a little confusing, because as I mentioned some of the optional Timoni components do use the standard kubernetes namespaces and if you don't dig into where those are configured it might seem built-in/immutable.