Ability to provide labels via devfile

[deboer-tim]

Is your feature request related to a problem? Please describe. Labels are often used to annotate Kubernetes deployments with information about the runtime, contents of the container, or other information. For example: "app.kubernetes.io/name=spring-boot". This information is used by other tools to decide what icons to use, decide which actions should be available, etc.

Currently devfiles do not contain label information so tools like odo use the devfile name to assign labels, but the result is that some labels that should exist don't, or have values that do not match what they would be if someone pushed the container through a build or other tools.

Describe the solution you'd like Proposal: Add label information as optional metadata, e.g.:

• label: ["app.kubernetes.io/name=spring-boot", ...]

Describe alternatives you've considered We could try mapping devfile name to labels or using some kind of detection or heuristics, but these would force naming patterns on devfiles, require hard-coding, and are unlikely to end up with consistent labels in all cases.

[sleshchenko]

There is already existing issue for labels, but I'm going to close that one, since this seems to have a bit more context, just a bit https://github.com/devfile/api/issues/107

[kadel]

Maybe something like this?

schemaVersion: 2.0.0
metadata:
  name: spring
  labels: 
    - app.kubernetes.io/name: spring-boot
    - app.kubernetes.io/instance: backend

Tools should interpret this as: Add app.kubernetes.io/name: spring-boot and app.kubernetes.io/instance: backend labels to every k8s resource that you create based on information in this Devfile.

[elsony]

Is this information always static for a given devfile or do we need to provide a way for tools to provide the name programmatically?

Take odo for example, someone will do an odo create component and supply with the component name, I would expect the deployed name to be app.kubernetes.io/instance to be the component name. The same for ODC, during an import from devfile scenario, the user can specify the app name during the import flow. I'd expect the app name label that we created will be set to the app name that the user input. Burning that info into the devfile will mean that the tools who want to deploy the app will end up having to modify the devfile (that'll trigger a resource change in git).

I think we'll need to provide this kind of labels field for users to inject their custom labels. For generic labels like the app name, should we allow using some pre-defined variables, say ${APP_NAME} (similar to the ${PROJECT_ROOT}) where the tools can just substitute the value on the fly?

As a side note, labels may be a bit too generic and it sounds like a display name of the devfile. Should we use something like deployLabels to make it clearer?

[deboer-tim]

For a static label like app.kubernetes.io/name, there is no way that tools would know what label(s) should be set or what value to use, and that's what this issue is trying to solve. For an implied label like app.kubernetes.io/instance, tools should set it but it is dynamic and would be detrimental to put in the devfile. IMHO we should just document that tools should set it. There is little point putting this in the devfile via a variable since it would always exist and be boilerplate. I think we probably are going to hit the last class of labels you describe where variables are required to set it properly. Unless there's an existing case I would defer this though - it's easy enough to add global variables later.

I see what you're saying about 'labels' being generic, but I don't love deployLabels... can't think of anything better atm.

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity. Remove stale label or comment or this will be closed in 60 days.