fix(chart/opensearch-dashboards): mapper_parsing_exception - tried to parse field [app] as object, but found a concrete value

[ainthapanya-sqc]

Description

This pull request addresses an issue where using the app label causes conflicts with object mapping in OpenSearch Dashboards. To resolve this, the app label has been replaced with the app.kubernetes.io/name label across the codebase.

Issues Resolved

• [BUG][opensearch-dashboards] mapper_parsing_exception - tried to parse field [app] as object, but found a concrete value #628

Check List

• Commits are signed per the DCO using --signoff

For any changes to files within Helm chart directories:

• Helm chart version bumped
• Helm chart CHANGELOG.md updated to reflect change

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[DandyDeveloper]

@ainthapanya-sqc Where's the original chart you used for Fluent Bit to reproduce this? There's lots that float around,

Also, that mapping parser exceptions should be coming from Opensearch API downstream to Fluent when it attempts to bulk push the docs.

Are you sure your mapping on the index aren't misconfigured? As the implication is that an index mapping is wrong on your index (Object, not String/Keyword for example.)

[ainthapanya-sqc]

@DandyDeveloper I had used Fluent Bit Helm chart 0.48.3.

Are you sure your mapping on the index aren't misconfigured? As the implication is that an index mapping is wrong on your index (Object, not String/Keyword for example.)

Pretty sure, the field kubernetes.labels.app should be of type object
However this helm chart, seems to have the kubernetes.labels.app field as a string.

There are other apps/deployments which are using appropriate labels and is working out of the box.

As a workaround, I needed to manually modify kubernetes.labels.app from string to an object in this helm chart.

Additionally, this may help with some alignment with the common/recommended labels.
https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/#labels

[DandyDeveloper]

@ainthapanya-sqc Okay, sorry I see the problem you're having. It's because in our manifests, we're using app as a label instead of the commonly found object of app.kubernetes.io/name etc. The fluent-bit parser is presumably grabbing logs throughout your cluster and funneling into the same index.

We should actually use the existing _helper template:

{{/*
Selector labels
*/}}
{{- define "opensearch-dashboards.selectorLabels" -}}
app.kubernetes.io/name: {{ include "opensearch-dashboards.name" . }}
app.kubernetes.io/instance: {{ .Release.Name }}
{{- end }}

Can you update to use this and make sure the DCO stuff is done? Then I'll approve.

[DandyDeveloper]

@ainthapanya-sqc Need to sort out the DCO related checks, but the code itself LGTM!

[ainthapanya-sqc]

@DandyDeveloper may need your help in approving the workflow.

[DandyDeveloper]

@ainthapanya-sqc Triggered them. I'll keep an eye out.

[DandyDeveloper]

@peterzhuamazon We're good to merge this whenever you're happy.

[ainthapanya-sqc]

@DandyDeveloper Thoughts on next steps?

[DandyDeveloper]

@ainthapanya-sqc I'll merge this if everything passes.

[ainthapanya-sqc]

@ainthapanya-sqc I'll merge this if everything passes.

thanks, this seemed to fix the errors, although had to recreate the deployment resources, as the labels were immutable.