Dashboard tags

[AntoineThebaud]

Proposal

We probably want the ability to tag dashboards, to enable another convenient way to search for the right one(s).

[Nexucis]

We had a brainstorming with @ibakshay and @dougkirkley about this feature. Here a summary:

1. First point was about where to store these tags. Tags are used to filter and search a resources, so there is no point to put them in the spec. So it has to go in the metadata. Another argument about not putting them in the spec is when you are listing the dashboard, you just want to get the metadata as it is lighter and faster to get them. spec are easily heavier.

2. So tags needs to go to metadata. In Perses we are, as much as possible, following the k8s data-model. And k8s does not provide anything related to a tag. So to simulate a tag with k8s, you would have to store them in the labels or annotations. But then you need to differentiate the regular labels from the tags. The only way to do that is to put in place a convention that will be easily broken. For example:

metadata:
  name: test
  labels:
    tag.barchart: "true"
    tag.graph: "true"
    tag.panel-tests: "true"
    foo: bar

We could prefix the labels by tag which will induce from the frontend side a parsing. And that's something would be great to avoid.

On this particular point, an idea would be for once to diverge from the k8s data-model and introduce a new field tags in the Perses medatada:

Kind: Dashboard
metadata:
  name: test
  tags:
  - oncall
  - high_severity

With this way, the UI doesn't need to implement a particular logic to get the tags.

3. But then when we are using CRs, how we will store these tags ? On this particular point, it will be the job of the perses-operator to propose and implement a convention to extract the tags from the labels or from the annotations.

4. Last concerning point: Are we sure we want tags and not labels ? It's worth to think twice about it as it will impact every resources proposed in Perses. So better to be sure about what we want. Besides with the fuzzy search bar, do we really need another thing to filter dashboards ? I believe the searching bar can handle most of the cases

[ibakshay]

@Nexucis Thank you very much for the summarisation. Let us maybe discuss this feature in the next weekly meeting and brainstorm further with others.

@jgbernalp Would love to get your feedback, especially on the perses-operator side :)

[nicolastakashi]

I'm wondering if annotations would be a better place to store tags, usually annotations in Kubernetes are used to applications store informations in there and retrieve it later.

It would fit nice as a label if it was only one label, but since a dash can have as many labels as the user decide, I'd probably store under annotations with map of key value.

wdyt?

[dougkirkley]

I guess I could see something like that working. I was looking up some examples and there are a few in the k8s docs around comma delimited lists.

https://kubernetes.io/docs/reference/labels-annotations-taints/#applyset-kubernetes-io-additional-namespaces

Kind: Dashboard
metadata:
  annotations:
    dashboard.perses.dev/tags: "oncall,high_severity"

[dougkirkley]

Also, I already had a PR merged into the operator side to enable adding annotations to the resources, so that should be supported already with minimal changes.

[jgbernalp]

I think adding a new tags field in the metadata will be beneficial for the UI, I think is great to be able to group dashboards in addition to the current hierarchical project structure. From the operator side, we are already doing some mapping between Perses metadata and k8s metadata, so it would be a good idea to follow @dougkirkley example with annotations. Nothing stops users from adding more labels or annotations in the CR, but we would have a clear place to store and sync between the intended tags for dashboards created in Perses. I think we should use tags instead of labels as labels can be used for other purposes specific to k8s, like reconciling a dashboard in a specific instance.

[ibakshay]

Yes, I also agree that having tags as k8s annotations is a good idea. For example, even helm is leveraging kubernetes annotations for specifying all the helm hooks. For example, have a look at their hook documentation here.

[nicolastakashi]

I'm wondering if UI couldn't read from annotations as well, I don't have a strong opinion on having tags as part of the spec, but it looks like metadata, so would be nice store on metadata and teach Ui leverage the metadata no?

[Nexucis]

On my side, I prefer to keep the UI stupid and simple with no parsing and convention.

But overall, it seems we are reaching a consensus:

In Perses core (perses/perses)

• Tags are in the metadata
• Tags are in a dedicated field named tags like

Kind: Dashboard
metadata:
  name: test
  tags:
  - oncall
  - high_severity

Since it's in the metadata, tags will be available for all Perses resources (datasource, project, roles etc.)

In k8s Custom Resource (perses/perses-operator)

• Tags are in the annotations
• They are in a single value, separated by a comma and identified by a unique key dashboard.perses.dev/tags or perhaps just perses.dev/tags. Like that it's more generic and this thing can be applied for other resources like the datasource.

kind: PersesDashboard
apiVersion: persesdashboards.perses.dev/v1alpha1
metadata:
  name: test
  namespace: monitoring
  annotations:
    perses.dev/tags : "oncall,high_severity"

Then the operator will implement the translation logic to have the tags in the corresponding field in Perses.

Anyone disagree ?

[ibakshay]

On my side, I prefer to keep the UI stupid and simple with no parsing and convention.

But overall, it seems we are reaching a consensus:

In Perses core (perses/perses)

• Tags are in the metadata
• Tags are in a dedicated field named tags like

Kind: Dashboard metadata: name: test tags:

• oncall
• high_severity Since it's in the metadata, tags will be available for all Perses resources (datasource, project, roles etc.)

In k8s Custom Resource (perses/perses-operator)

• Tags are in the annotations
• They are in a single value, separated by a comma and identified by a unique key dashboard.perses.dev/tags or perhaps just perses.dev/tags. Like that it's more generic and this thing can be applied for other resources like the datasource.

kind: PersesDashboard apiVersion: persesdashboards.perses.dev/v1alpha1 metadata: name: test namespace: monitoring annotations: perses.dev/tags : "oncall,high_severity" Then the operator will implement the translation logic to have the tags in the corresponding field in Perses.

Anyone disagree ?

I agree with your proposal! 🚀💯

[Nexucis]

I have started some works around this topic. What remains is where are we displaying the dashboards tags and how/where we can modify them