Go to file
Siva Kanakala 26449eb9c8
Merge pull request #168 from skanakal/forwardport-51331
[Forwardport-v2.13][rancher-monitoring 77.9.1-rancher.4] Don't install Fleet ServiceMonitor on downstream clusters
2025-10-24 11:52:50 +05:30
.github/ISSUE_TEMPLATE
assets make charts 2025-10-24 11:05:26 +05:30
charts make charts 2025-10-24 11:05:26 +05:30
config
deprecated-packages
dev-scripts
docs
packages remove space 2025-10-24 10:25:37 +05:30
scripts fix(build): Ensure bin directory exists and is executable before download 2025-10-07 11:22:40 +05:30
.gitignore
Makefile
README.md
index.yaml make charts 2025-10-24 11:05:26 +05:30

README.md

ob-team-charts

A repo for Rancher Observability & Backups team's charts - a canonical dev spot just before rancher/charts.

What O&B projects use this repo?

This covers the following O&B team charts:

  • rancher-monitoring,
  • rancher-project-monitoring,
  • prometheus-federator, and
  • rancher-logging

This is where we apply the majority of the Rancher specific changes to these charts. None of the changes we apply at this level should be specific to a single Rancher minor version.

How do we manage Chart version numbers?

The short version, most charts should use this syntax: {upstream version}-rancher.{incrementing number}.

Where each new {upstream version} resets the {incrementing number}. The result being that for any upstream version that we release, we will also be able to track what rancher specific changes were applied. And that this version is universal across all Rancher minor versions that support a given {upstream version}.

For more specifics on why this format is used, see: How do we manage Chart versions across this repo and rancher/charts?

How are PRs merged into this repo?

Due to how we manage the version numbers here, read the section above for detail, we must ensure that we only merge PRs after charts are valdiated. This means that PRs must have both: approving review from O&B team, and a validation comment on the PR or issue from O&B QA team.

This way every version published to main is a "safe version" - meaning while they may still have bugs, none should have critical flaws. This gives us greater confidence to ship multiple changes to rancher/charts at one time (when we release) - as all changes were tested at least once before that.

For more on what details to provide QA for testing, see: How to test charts straight from ob-team-charts.

How does rebasing for Rancher Monitoring charts work with this repo?

Overall the process isn't too different, however how we manage a particular upstream version will be different. In the new system, we will suffix each upstream version with a -rancher.{num} identifier.

Using that will give us a better identifier for our Rancher specific modifications that we use across Rancher minor versions. Specifically some other ways this will benfit our team is:

  • O&B team maintains a single canonical version of upstream chart changes,
  • rancher-monitoring and rancher-project-monitoirng rebase can be a single PR
    • Then followed up by PRs in rancher/prometheus-federator and all synced to rancher/charts in unison.

Please review the Monitoring Rebase doc for more details on the process this repo allows.