fix: set a different component label on migration Job

[AlexandrePicosson]

Description

What problem is being solved?

I deploy OpenFGA using the chart with the migration Job and the Horizontal Pod Autoscaler (HPA) enabled. This creates an issue where the HPA is matching the migration Job pod because the matching of the HPA is based on the matchLabels of the Deployment. This issue is known and tracked upstream here: kubernetes/enhancements#5325. While we wait for the Kubernetes team to address it, the best solution is to have a unique set of matchLabels for the Deployment that should not be present on other pods.

How is it being solved?

I changed the app.kubernetes.io/component label for the migration Job and the Pods managed by this Job as well as the test Pod.

Applying the component label outside of the common labels seems to be quite standard across charts I frequently use.

What changes are made to solve it?

Here is a diff of the template rendered with the following command:

helm template ./openfga --set datastore.engine=postgres --set datastore.applyMigrations=true --set datastore.migrationType=job --set autoscaling.enabled=true

spec.selector  (document #5)
  + one map entry added:
    app.kubernetes.io/component: authorization-controller

spec.selector.matchLabels  (document #6)
  + one map entry added:
    app.kubernetes.io/component: authorization-controller

metadata.labels.app.kubernetes.io/component  (document #8)
  ± value change
    - authorization-controller
    + connection-test

metadata.labels.app.kubernetes.io/component  (document #9)
  ± value change
    - authorization-controller
    + migration

spec.template.metadata.labels.app.kubernetes.io/component  (document #9)
  ± value change
    - authorization-controller
    + migration

References

• upstream k8s issue: HPA: Improve pod selection accuracy across workload types kubernetes/enhancements#5325

Review Checklist

• I have clicked on "allow edits by maintainers".
• I have added documentation for new/changed functionality in this PR or in a PR to openfga.dev [Provide a link to any relevant PRs in the references section above]
• The correct base branch is being used, if not main
• I have added tests to validate that the change in functionality is working as expected

Summary by CodeRabbit

• Chores

  • Updated Helm chart version to 0.2.46

• New Features

  • Added new Kubernetes labels for migration Jobs to improve resource identification and management.

[linux-foundation-easycla]

• ❌ - login: @AlexandrePicosson / name: Alexandre-P . The commit (b5ed816) is not authorized under a signed CLA. Please click here to be authorized. For further assistance with EasyCLA, please submit a support request ticket.

[coderabbitai]

Walkthrough

Version bump to 0.2.46 accompanied by introduction of a new migrate.labels template for migration-specific Kubernetes labels. The app.kubernetes.io/component: authorization-controller label was relocated from common labels to selectorLabels, and Job templates now reference the new migration labels template instead of the generic labels template.

Changes

Cohort / File(s)	Summary
Version Update charts/openfga/Chart.yaml	Chart version incremented from 0.2.45 to 0.2.46
Label Template Definitions charts/openfga/templates/_helpers.tpl	Added new exported template migrate.labels containing migration-specific Kubernetes labels; moved app.kubernetes.io/component: authorization-controller from common labels to selectorLabels
Job Label References charts/openfga/templates/job.yaml	Updated metadata.labels and template.metadata.labels to use migrate.labels template instead of openfga.labels (two locations)

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

• Verify migrate.labels template structure and that all required migration-specific labels are included
• Confirm the relocation of app.kubernetes.io/component label does not impact label selector matching for existing OpenFGA pods
• Ensure both Job manifest label references (top-level and pod template) are correctly applied

Possibly related PRs

• Embed CommonLabels into job pod spec #229: Modifies migration job labels in the same charts/openfga/templates/job.yaml file with similar label restructuring for migration workloads

Suggested reviewers

• rhamzeh

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title Check	✅ Passed	The pull request title "fix: set a different component label on migration Job" directly and clearly describes the primary change in the changeset. The PR's main objective is to prevent the Horizontal Pod Autoscaler from matching the migration Job pod by changing the app.kubernetes.io/component label from "authorization-controller" to "migration", which is exactly what the title conveys. The title is concise, specific, and uses appropriate conventional prefixing ("fix:"), making it clear to teammates reviewing the history what issue is being addressed.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

Tip

📝 Customizable high-level summaries are now available in beta!

You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.

• Provide your own instructions using the high_level_summary_instructions setting.
• Format the summary however you like (bullet lists, tables, multi-section layouts, contributor stats, etc.).
• Use high_level_summary_in_walkthrough to move the summary from the description to the walkthrough section.

Example instruction:

"Divide the high-level summary into five sections:

1. 📝 Description — Summarize the main change in 50–60 words, explaining what was done.
2. 📓 References — List relevant issues, discussions, documentation, or related PRs.
3. 📦 Dependencies & Requirements — Mention any new/updated dependencies, environment variable changes, or configuration updates.
4. 📊 Contributor Summary — Include a Markdown table showing contributions:
   | Contributor | Lines Added | Lines Removed | Files Changed |
5. ✔️ Additional Notes — Add any extra reviewer context.
   Keep each section concise (under 200 words) and use bullet or numbered lists for clarity."

Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

charts/openfga/templates/_helpers.tpl (1)

66-85: LGTM: Well-documented migration labels template.

The new migrate.labels template correctly provides a distinct label set with component: migration, preventing HPA from selecting migration Job pods. The explanatory comment clearly documents the rationale.

Optional: Consider reducing duplication with a parameterized helper.

The migrate.labels template duplicates most of openfga.labels. For better maintainability, you could create a base label template that accepts a component parameter:

{{- define "openfga.baseLabels" -}}
helm.sh/chart: {{ include "openfga.chart" . }}
app.kubernetes.io/name: {{ include "openfga.name" . }}
app.kubernetes.io/instance: {{ .Release.Name }}
app.kubernetes.io/component: {{ .component }}
{{- with .root.Values.commonLabels }}
{{ . | toYaml }}
{{- end }}
{{- if .root.Chart.AppVersion }}
app.kubernetes.io/version: {{ .root.Chart.AppVersion | quote }}
{{- end }}
app.kubernetes.io/managed-by: {{ .root.Release.Service }}
app.kubernetes.io/part-of: openfga
{{- end }}

Then call it from both templates:

{{- define "openfga.labels" -}}
{{- include "openfga.baseLabels" (dict "component" "authorization-controller" "root" .) }}
{{- end }}

{{- define "migrate.labels" -}}
{{- include "openfga.baseLabels" (dict "component" "migration" "root" .) }}
{{- end }}

This approach would centralize the label structure and reduce future maintenance burden.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 8e85901 and 3bd55ce.

📒 Files selected for processing (3)

• charts/openfga/Chart.yaml (1 hunks)
• charts/openfga/templates/_helpers.tpl (1 hunks)
• charts/openfga/templates/job.yaml (2 hunks)

🔇 Additional comments (3)

charts/openfga/Chart.yaml (1)

6-6: LGTM: Appropriate version bump.

The patch version increment is correct for this bug fix.

charts/openfga/templates/job.yaml (1)

7-7: LGTM: Correctly applies migration-specific labels.

The Job manifest now uses migrate.labels for both the Job metadata and Pod template, ensuring these pods have component: migration instead of component: authorization-controller. This prevents the HPA from inadvertently selecting migration Job pods.

Also applies to: 23-23

charts/openfga/templates/_helpers.tpl (1)

63-64: LGTM: Component label correctly positioned in selector labels for proper pod targeting.

The change to include app.kubernetes.io/component: authorization-controller in openfga.selectorLabels is correct. This ensures that:

• Deployment selectors (deployment.yaml) explicitly match pods with this label
• Service and ServiceMonitor selectors properly target these pods
• Migration Job pods (using migrate.labels with component: migration) remain separate and won't interfere with HPA scaling

HPA correctly targets the Deployment by name rather than label selectors, so this change has no negative impact. The label structure maintains proper pod segregation and is backwards compatible.