From a28fa89fa5ccf767103313b4bbd54257431d9d78 Mon Sep 17 00:00:00 2001 From: Yetkin Timocin Date: Thu, 13 Aug 2026 14:07:22 -0700 Subject: [PATCH 1/2] fix: publish the real chart version to the GitHub Pages index The GitHub Pages publish never passed chart_version/app_version to helm-gh-pages, so it packaged charts/*/Chart.yaml verbatim - both pinned in-tree at version 0.1.0, appVersion v0.1.0. Every release republished "hub-agent 0.1.0" and "member-agent 0.1.0", and because `helm repo index --merge` lets the newly generated entry win a version collision, each release silently replaced the contents of that same 0.1.0 tarball rather than adding a version. The live index still lists only 0.1.0. The OCI publish has always passed both values via `make helm-push`, so this affects the `helm repo add` channel only. For users of that channel, `helm install kubefleet/hub-agent` with no --version has always resolved to 0.1.0, and since the chart defaults image.tag to .Chart.AppVersion, those installs have been running v0.1.0 images. After this change the same command resolves to the current release. charts/README.md now carries that warning at the bare install and upgrade commands, drops a --version example that never existed on this channel, and stops telling contributors to bump Chart.yaml fields the pipeline overrides. The stale 0.1.0 entry survives the index merge and still appears in `helm search repo kubefleet --versions`; removing it would break anyone pinning it, so it is left alone here. Nothing already published is modified or deleted by this change. A verification step reads the gh-pages branch back and fails the job unless each chart was published with the release tag as its appVersion and listed in index.yaml - the file `helm repo add` actually reads. Unknown inputs to an action are only a warning, so a rename or typo would otherwise restore the old behaviour with a green build. Part of #693. Signed-off-by: Yetkin Timocin --- .github/workflows/chart.yml | 44 +++++++++++++++++++++++++++++++++++++ charts/README.md | 39 +++++++++++++++++++++++--------- 2 files changed, 73 insertions(+), 10 deletions(-) diff --git a/.github/workflows/chart.yml b/.github/workflows/chart.yml index 57c7965c5..59384affe 100644 --- a/.github/workflows/chart.yml +++ b/.github/workflows/chart.yml @@ -43,14 +43,58 @@ jobs: with: submodules: true fetch-depth: 0 + # Without chart_version/app_version the action packages charts/*/Chart.yaml + # verbatim, and those are pinned in-tree at 0.1.0/v0.1.0. Every release + # therefore republished "hub-agent 0.1.0" with appVersion v0.1.0 - and + # because `helm repo index --merge` lets the newly generated entry win a + # version collision, each release silently replaced the contents of the + # same 0.1.0 tarball. The OCI publish below has always passed both values + # (see `make helm-push`); this brings the index in line with it. - name: Publish Helm chart to GitHub Pages uses: stefanprodan/helm-gh-pages@0ad2bb377311d61ac04ad9eb6f252fb68e207260 # v1.7.0 with: token: ${{ secrets.GITHUB_TOKEN }} charts_dir: charts target_dir: charts + chart_version: ${{ needs.export-registry.outputs.version }} + app_version: ${{ needs.export-registry.outputs.tag }} linting: on + # Unknown inputs to an action are a warning, not an error, so a rename or + # typo above would silently restore the old behaviour with a green build. + # Check the branch the action just wrote instead of trusting that it + # accepted them. + - name: Verify the published index carries this release + env: + TAG: ${{ needs.export-registry.outputs.tag }} + CHART_VERSION: ${{ needs.export-registry.outputs.version }} + run: | + set -euo pipefail + git fetch origin gh-pages + index="$(git cat-file blob "FETCH_HEAD:charts/index.yaml")" + for chart in hub-agent member-agent; do + packaged="charts/${chart}-${CHART_VERSION}.tgz" + if ! git cat-file -e "FETCH_HEAD:${packaged}" 2>/dev/null; then + echo "::error::gh-pages has no ${packaged}; the chart was not published for this release." + exit 1 + fi + app_version="$(git cat-file blob "FETCH_HEAD:${packaged}" \ + | tar -xzO "${chart}/Chart.yaml" \ + | awk -F': ' '/^appVersion:/ {gsub(/"/, "", $2); print $2}')" + if [ "${app_version}" != "${TAG}" ]; then + echo "::error::gh-pages ${chart} appVersion (${app_version}) does not match release tag (${TAG})" + exit 1 + fi + # index.yaml is what `helm repo add` reads; a tarball on the branch + # that the index does not list is invisible to users, so assert the + # index gained this version rather than only that the file exists. + if ! grep -qF "${chart}-${CHART_VERSION}.tgz" <<<"${index}"; then + echo "::error::gh-pages charts/index.yaml does not list ${chart} ${CHART_VERSION}" + exit 1 + fi + echo "✅ gh-pages publishes and indexes ${chart} ${CHART_VERSION} (appVersion ${app_version})" + done + publish-oci: needs: export-registry runs-on: ubuntu-latest diff --git a/charts/README.md b/charts/README.md index da0068a4b..0aeb402f2 100644 --- a/charts/README.md +++ b/charts/README.md @@ -51,6 +51,13 @@ helm install member-agent oci://ghcr.io/kubefleet-dev/kubefleet/charts/member-ag ### Option 2: Traditional Helm Repository +> **Heads up if you already use this repository.** Until recently every release +> was published here as chart version `0.1.0` with `appVersion v0.1.0`, so an +> install from this channel that did not set `image.tag` has been running the +> `v0.1.0` images. Releases now publish their real version, which means the +> commands below resolve to the current release rather than to `0.1.0`. The OCI +> registry above was never affected. + Add the repository and install from it: ```bash @@ -88,13 +95,17 @@ helm install hub-agent oci://ghcr.io/kubefleet-dev/kubefleet/charts/hub-agent \ #### Traditional Repository +> **Note:** `helm search repo kubefleet --versions` still lists a stale `0.1.0` +> entry from before per-release versions were published. Releases cut before +> that change are available from the OCI registry only. + ```bash # List available versions helm search repo kubefleet --versions -# Install a specific version (e.g., v0.3.0 release) +# Install a specific version (replace VERSION with one listed above) helm install hub-agent kubefleet/hub-agent \ - --version 0.3.0 \ + --version VERSION \ --namespace fleet-system \ --create-namespace ``` @@ -122,11 +133,18 @@ helm upgrade hub-agent kubefleet/hub-agent --namespace fleet-system helm upgrade member-agent kubefleet/member-agent --namespace fleet-system ``` +If you have been tracking this repository since before per-release versions +were published, this upgrade moves off `0.1.0` for the first time and can cross +several releases at once. Read the release notes for the whole span, not just +the newest entry, and note that unless you set `image.tag` the running image +version moves with the chart's `appVersion`. + ## Chart Publishing -Charts are automatically published to both locations when: -- Changes are pushed to the `main` branch affecting chart files -- A version tag (e.g., `v1.0.0`) is created +Charts are published to both locations when a stable version tag (e.g. +`v1.0.0`) is pushed. The push trigger filters out release-candidate tags +(e.g. `v1.0.0-rc.1`), so an RC does not reach the chart index by cutting a tag; +a maintainer can still publish one deliberately via `workflow_dispatch`. **Published Locations:** - **OCI Registry**: `oci://ghcr.io/kubefleet-dev/kubefleet/charts/{chart-name}` @@ -176,11 +194,12 @@ For detailed documentation on each chart including configuration parameters, see ## Contributing When making changes to charts: -1. Update the chart version in `Chart.yaml` following [Semantic Versioning](https://semver.org/) -2. Update the `appVersion` if the application version changes -3. Run `helm lint` to validate your changes -4. Update the chart's README.md with any new parameters or changes -5. Test the chart installation locally before submitting a PR +1. Leave `version` and `appVersion` in `Chart.yaml` alone — the release + workflow injects the release version at package time, so the in-tree values + are placeholders and are not what gets published +2. Run `helm lint` to validate your changes +3. Update the chart's README.md with any new parameters or changes +4. Test the chart installation locally before submitting a PR ## Support From 3733db9a80c5224339808c8b28cd41993f5c4221 Mon Sep 17 00:00:00 2001 From: Yetkin Timocin Date: Tue, 18 Aug 2026 12:48:33 -0700 Subject: [PATCH 2/2] docs: describe what the 0.1.0 chart index actually deployed The warning added alongside the index fix said users had "been running the v0.1.0 images". That is not what happened, and the correction matters because the real outcome is worse for some readers and harmless for others. Walking all 50 revisions of the published tarball on gh-pages: until March 2026 the chart pinned image.tag: main against ghcr.io/azure/fleet. That tag exists and pullPolicy is Always, so those installs came up fine and have been re-pulling unreleased builds on every pod restart ever since - and ghcr.io/azure/fleet/hub-agent:main is still being rebuilt today, from outside this repository's release process. Only installs from February 2026 onward hit ImagePullBackOff, because 0.1.0 and v0.1.0 were never pushed to ghcr.io/kubefleet-dev/kubefleet. The two eras also interleaved rather than replacing each other, so what a cluster runs depends on when it last ran `helm repo update` rather than on any release. Replace the single claim with a table of what that one 0.1.0 slot served over time, ordered by severity, and broaden the diagnostic: the tell is any image that is not a release tag, not only :v0.1.0. A reader in the first row has no symptom to notice. Also drop two claims that did not survive checking: the OCI channel was not "never affected" (chart 0.1.0 pins the same floating tag, and 0.2.1-test names a missing image), and earlier releases were not "available from the OCI registry only" - no chart carrying its own release version exists for them anywhere. Fold six near-duplicate warnings into one section the others link to, which also fixes an anchor that pointed at a restatement rather than at the guidance. Add an "am I affected" command and an upgrade recipe that re-passes member-agent's hub connection, since a bare upgrade resets it to the chart's placeholders. Chart.yaml comments told contributors to bump version and appVersion on every change, contradicting the rule this PR documents. They are release-time placeholders, and installing from a git checkout needs --set image.tag because of it. member-agent's parameter table documented four wrong defaults, including image.tag: v0.1.0 - the exact broken value - and omitted the refresh-token image entirely. Signed-off-by: Yetkin Timocin --- charts/README.md | 133 +++++++++++++++++++++++++++++---- charts/hub-agent/Chart.yaml | 16 ++-- charts/hub-agent/README.md | 24 +++++- charts/member-agent/Chart.yaml | 16 ++-- charts/member-agent/README.md | 31 ++++++-- 5 files changed, 183 insertions(+), 37 deletions(-) diff --git a/charts/README.md b/charts/README.md index 0aeb402f2..6001cbd55 100644 --- a/charts/README.md +++ b/charts/README.md @@ -51,12 +51,11 @@ helm install member-agent oci://ghcr.io/kubefleet-dev/kubefleet/charts/member-ag ### Option 2: Traditional Helm Repository -> **Heads up if you already use this repository.** Until recently every release -> was published here as chart version `0.1.0` with `appVersion v0.1.0`, so an -> install from this channel that did not set `image.tag` has been running the -> `v0.1.0` images. Releases now publish their real version, which means the -> commands below resolve to the current release rather than to `0.1.0`. The OCI -> registry above was never affected. +> **Important:** every release before this fix reached this index as chart +> `0.1.0`, which depending on when you installed it either failed to start or +> silently tracked the unreleased `main` branch. Releases now publish their real +> version. If you already installed from here, see +> [Migrating from the 0.1.0 chart index](#migrating-from-the-010-chart-index). Add the repository and install from it: @@ -95,9 +94,13 @@ helm install hub-agent oci://ghcr.io/kubefleet-dev/kubefleet/charts/hub-agent \ #### Traditional Repository -> **Note:** `helm search repo kubefleet --versions` still lists a stale `0.1.0` -> entry from before per-release versions were published. Releases cut before -> that change are available from the OCI registry only. +> **Note:** `helm search repo kubefleet --versions` still lists the stale +> `0.1.0` entry described in +> [Migrating from the 0.1.0 chart index](#migrating-from-the-010-chart-index) — +> do not install it — along with an unrelated `arc-member-cluster-agents-helm-chart` +> entry that `--merge` has preserved since 2025. Charts carrying their own +> release version exist for `v0.2.2`, `v0.3.0`, and `v0.3.1`, in the OCI registry +> only; no such chart exists for any earlier release on either channel. ```bash # List available versions @@ -133,11 +136,102 @@ helm upgrade hub-agent kubefleet/hub-agent --namespace fleet-system helm upgrade member-agent kubefleet/member-agent --namespace fleet-system ``` -If you have been tracking this repository since before per-release versions -were published, this upgrade moves off `0.1.0` for the first time and can cross +If you have been tracking this repository since before per-release versions were +published, this upgrade moves off `0.1.0` for the first time and can cross several releases at once. Read the release notes for the whole span, not just -the newest entry, and note that unless you set `image.tag` the running image -version moves with the chart's `appVersion`. +the newest entry, and see +[Migrating from the 0.1.0 chart index](#migrating-from-the-010-chart-index). + +## Migrating from the `0.1.0` chart index + +The action that maintains the GitHub Pages index was never told the release +version, so it packaged the in-tree `Chart.yaml` verbatim — always version +`0.1.0`. Because `helm repo index --merge` lets a freshly generated entry win a +version collision, every publish silently replaced the contents of that same +`0.1.0` tarball. Until this fix, the index held exactly one entry per chart, and +that one entry was rewritten 50 times: on releases, and — until February 2026 — +on any push to `main` that touched `charts/`. What an install got depended on +when you last ran `helm repo update`, not on any release. + +Because the in-tree values changed over time, that single `0.1.0` slot has +deployed three different things: + +| Published | Rendered image | Effect | +| --- | --- | --- | +| Oct 2025 – Apr 2026 | `ghcr.io/azure/fleet/hub-agent:main` | **Works, and tracks unreleased code.** `main` is a floating tag and `pullPolicy` is `Always`, so every pod restart pulls whatever was last built from `main`. | +| Feb – Mar 2026 | `ghcr.io/kubefleet-dev/kubefleet/hub-agent:0.1.0` | `ImagePullBackOff` — that tag does not exist. | +| Apr 2026 – this fix | `ghcr.io/kubefleet-dev/kubefleet/hub-agent:v0.1.0` | `ImagePullBackOff` — that tag does not exist either. | + +These interleaved rather than replacing one another: publishes ran from +different refs, so three weeks after the broken chart first appeared the index +went back to serving the `:main` one, and did so for a month — from 2026-03-10 +until 2026-04-08. Which of the three you got depends on when you last ran +`helm repo update`. + +The first row is the one worth acting on. There is no `v0.1.0` release of +KubeFleet — the `0.1` series ran `v0.1`, `v0.1.1`, `v0.1.2` — and neither +`0.1.0` nor `v0.1.0` was ever pushed to `ghcr.io/kubefleet-dev/kubefleet`. So the +later two rows fail loudly and harmlessly. An install from the first row came up +fine and has been following `main` ever since. + +That drift has not stopped. `ghcr.io/azure/fleet/hub-agent:main` is still being +rebuilt — the current image was built on 2026-08-04 — and nothing in this +repository publishes to `ghcr.io/azure/fleet`; it is outside the KubeFleet +release process entirely. A cluster in the first row is therefore still picking +up new, unreleased builds from a namespace this project does not control, and it +will keep doing so until you pin `image.tag`. There is no symptom to wait for: +those pods are healthy. + +Check what you are running: + +```bash +kubectl get deployment -n fleet-system \ + -o custom-columns='NAME:.metadata.name,IMAGE:.spec.template.spec.containers[*].image' +``` + +Anything that is not a release tag — `:main`, `:0.1.0`, `:v0.1.0`, or any +`ghcr.io/azure/fleet/*` image — came from this bug. Once a release has been +published with this fix in place, move to it: + +```bash +helm repo update +helm upgrade hub-agent kubefleet/hub-agent \ + --version VERSION \ + --namespace fleet-system + +# member-agent holds its hub connection in values, so re-pass them (or +# --reuse-values); a bare upgrade resets them to the chart's placeholders. +helm upgrade member-agent kubefleet/member-agent \ + --version VERSION \ + --namespace fleet-system \ + --set config.hubURL=https:// \ + --set config.hubCA= \ + --set config.memberClusterName= +``` + +Until such a release exists, the index offers only `0.1.0`; pull the chart from +the OCI registry instead. + + + +`member-agent` behaves the same way, with the added wrinkle that it runs two +images — the agent and the `refresh-token` sidecar — affected identically in +every row above, and needing two overrides rather than one. + +**The OCI registry.** Charts there have carried a real per-release version since +`0.2.2`, and from `0.2.2` on they render a published image. The two earlier ones +should not be used: `0.1.0` pins `ghcr.io/azure/fleet/hub-agent:main`, the same +floating tag as the first row above, and `0.2.1-test` renders a `0.2.1-test` +image that was never pushed. Pin `0.2.2` or later and the OCI channel is +unaffected. + +**Installing from a git checkout.** The in-tree `Chart.yaml` carries the same +`v0.1.0` placeholder, so a local `helm install ./charts/hub-agent` hits this too. +Pass `--set image.tag=VERSION` (and `--set refreshtoken.tag=VERSION` for +member-agent) with a published release tag. ## Chart Publishing @@ -156,14 +250,21 @@ The publishing workflow is defined in `.github/workflows/chart.yml`. ### Local Installation -For development and testing, you can install charts directly from the local repository: +For development and testing, you can install charts directly from the local +repository. The in-tree `Chart.yaml` carries a placeholder `appVersion` that does +not name a published image, so a local install has to say which images to run: ```bash -# Install from local path -helm install hub-agent ./charts/hub-agent --namespace fleet-system --create-namespace +# Install from local path (replace VERSION with a published release tag, e.g. v0.3.1) +helm install hub-agent ./charts/hub-agent \ + --namespace fleet-system \ + --create-namespace \ + --set image.tag=VERSION helm install member-agent ./charts/member-agent \ --namespace fleet-system \ --create-namespace \ + --set image.tag=VERSION \ + --set refreshtoken.tag=VERSION \ --set config.hubURL=https:// \ --set config.hubCA= \ --set config.memberClusterName= diff --git a/charts/hub-agent/Chart.yaml b/charts/hub-agent/Chart.yaml index efa8648a8..710d1485b 100644 --- a/charts/hub-agent/Chart.yaml +++ b/charts/hub-agent/Chart.yaml @@ -12,13 +12,15 @@ description: A Helm chart for hub agent # pipeline. Library charts do not define any templates and therefore cannot be deployed. type: application -# This is the chart version. This version number should be incremented each time you make changes -# to the chart and its templates, including the app version. -# Versions are expected to follow Semantic Versioning (https://semver.org/) +# The chart version, following Semantic Versioning (https://semver.org/). +# Placeholder: leave this alone when changing the chart. The release workflow +# packages charts with the release version, so this value is never published. version: 0.1.0 -# This is the version number of the application being deployed. This version number should be -# incremented each time you make changes to the application. Versions are not expected to -# follow Semantic Versioning. They should reflect the version the application is using. -# It is recommended to use it with quotes. +# The version of the application being deployed. Also a placeholder, which the +# release workflow overwrites with the release tag. Templates read it back as +# .Chart.AppVersion to default the image tag, so a published chart runs the +# image from the release it was published for. Installing straight from a git +# checkout gets this placeholder instead, which names no published image: pass +# --set image.tag with a released version. appVersion: "v0.1.0" diff --git a/charts/hub-agent/README.md b/charts/hub-agent/README.md index 7cc93551b..f97d9a503 100644 --- a/charts/hub-agent/README.md +++ b/charts/hub-agent/README.md @@ -22,6 +22,12 @@ helm install hub-agent oci://ghcr.io/kubefleet-dev/kubefleet/charts/hub-agent \ #### Option 2: Traditional Helm Repository +> **Important:** every release before this fix reached this index as chart +> `0.1.0`, which depending on when you installed it either failed to start or +> silently tracked the unreleased `main` branch. Releases now publish their real +> version. If you already installed from here, see +> [Migrating from the 0.1.0 chart index](../README.md#migrating-from-the-010-chart-index). + ```console # Add the KubeFleet Helm repository helm repo add kubefleet https://kubefleet-dev.github.io/kubefleet/charts @@ -33,8 +39,15 @@ helm install hub-agent kubefleet/hub-agent --namespace fleet-system --create-nam ### Local Installation from Source +The in-tree `Chart.yaml` carries a placeholder `appVersion` that names no +published image, so a local install has to say which image to run: + ```console -helm install hub-agent ./charts/hub-agent/ --namespace fleet-system --create-namespace +# Replace VERSION with a published release tag, e.g. v0.3.1 +helm install hub-agent ./charts/hub-agent/ \ + --namespace fleet-system \ + --create-namespace \ + --set image.tag=VERSION ``` ### Installation with cert-manager @@ -60,8 +73,9 @@ helm install hub-agent oci://ghcr.io/kubefleet-dev/kubefleet/charts/hub-agent \ --set enableWorkload=true \ --set enableWebhook=true -# Or using traditional repository +# Or using traditional repository (specify VERSION; see the note under Option 2) helm install hub-agent kubefleet/hub-agent \ + --version VERSION \ --namespace fleet-system \ --create-namespace \ --set useCertManager=true \ @@ -83,6 +97,12 @@ helm upgrade hub-agent oci://ghcr.io/kubefleet-dev/kubefleet/charts/hub-agent \ helm upgrade hub-agent kubefleet/hub-agent --namespace fleet-system ``` +> If you have tracked the traditional repository since before per-release +> versions were published, that second command moves off `0.1.0` for the first +> time and can cross several releases at once. Read the release notes for the +> whole span, and see +> [Migrating from the 0.1.0 chart index](../README.md#migrating-from-the-010-chart-index). + _See [parameters](#parameters) below._ _See [helm install](https://helm.sh/docs/helm/helm_install/) for command documentation._ diff --git a/charts/member-agent/Chart.yaml b/charts/member-agent/Chart.yaml index 6a5fd14b8..048486815 100644 --- a/charts/member-agent/Chart.yaml +++ b/charts/member-agent/Chart.yaml @@ -12,13 +12,15 @@ description: Helm chart for member agent. # pipeline. Library charts do not define any templates and therefore cannot be deployed. type: application -# This is the chart version. This version number should be incremented each time you make changes -# to the chart and its templates, including the app version. -# Versions are expected to follow Semantic Versioning (https://semver.org/) +# The chart version, following Semantic Versioning (https://semver.org/). +# Placeholder: leave this alone when changing the chart. The release workflow +# packages charts with the release version, so this value is never published. version: 0.1.0 -# This is the version number of the application being deployed. This version number should be -# incremented each time you make changes to the application. Versions are not expected to -# follow Semantic Versioning. They should reflect the version the application is using. -# It is recommended to use it with quotes. +# The version of the application being deployed. Also a placeholder, which the +# release workflow overwrites with the release tag. Templates read it back as +# .Chart.AppVersion to default the member-agent and refresh-token image tags, so +# a published chart runs the images from the release it was published for. +# Installing straight from a git checkout gets this placeholder instead, which +# names no published image: pass --set image.tag / --set refreshtoken.tag. appVersion: "v0.1.0" diff --git a/charts/member-agent/README.md b/charts/member-agent/README.md index b5429039b..009b14369 100644 --- a/charts/member-agent/README.md +++ b/charts/member-agent/README.md @@ -49,6 +49,12 @@ helm install member-agent oci://ghcr.io/kubefleet-dev/kubefleet/charts/member-ag #### Option 2: Traditional Helm Repository +> **Important:** every release before this fix reached this index as chart +> `0.1.0`, which depending on when you installed it either failed to start or +> silently tracked the unreleased `main` branch. Releases now publish their real +> version. If you already installed from here, see +> [Migrating from the 0.1.0 chart index](../README.md#migrating-from-the-010-chart-index). + ```console # Add the KubeFleet Helm repository helm repo add kubefleet https://kubefleet-dev.github.io/kubefleet/charts @@ -65,10 +71,16 @@ helm install member-agent kubefleet/member-agent \ ### From Local Source +The in-tree `Chart.yaml` carries a placeholder `appVersion` that names no +published image, so a local install has to say which images to run: + ```console +# Replace VERSION with a published release tag, e.g. v0.3.1 helm install member-agent ./charts/member-agent/ \ --namespace fleet-system \ --create-namespace \ + --set image.tag=VERSION \ + --set refreshtoken.tag=VERSION \ --set config.hubURL=https:// \ --set config.hubCA= \ --set config.memberClusterName= @@ -88,19 +100,28 @@ helm upgrade member-agent oci://ghcr.io/kubefleet-dev/kubefleet/charts/member-ag helm upgrade member-agent kubefleet/member-agent --namespace fleet-system ``` +> If you have tracked the traditional repository since before per-release +> versions were published, that second command moves off `0.1.0` for the first +> time and can cross several releases at once. Read the release notes for the +> whole span, and see +> [Migrating from the 0.1.0 chart index](../README.md#migrating-from-the-010-chart-index). + ## Parameters | Parameter | Description | Default | |:------------------------|:-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:-----------------------------------------------------| | replicaCount | The number of member-agent replicas to deploy | `1` | -| image.repository | Image repository | `ghcr.io/azure/azure/fleet/member-agent` | -| image.pullPolicy | Image pullPolicy | `IfNotPresent` | -| image.tag | The image tag to use | `v0.1.0` | +| image.repository | Image repository | `ghcr.io/kubefleet-dev/kubefleet/member-agent` | +| image.pullPolicy | Image pullPolicy | `Always` | +| image.tag | Image release tag (empty uses chart `appVersion`) | `""` | +| refreshtoken.repository | Refresh-token sidecar image repository | `ghcr.io/kubefleet-dev/kubefleet/refresh-token` | +| refreshtoken.pullPolicy | Refresh-token sidecar image pullPolicy | `Always` | +| refreshtoken.tag | Refresh-token sidecar release tag (empty uses chart `appVersion`) | `""` | | affinity | The node affinity to use for pod scheduling | `{}` | | tolerations | The toleration to use for pod scheduling | `[]` | -| resources | The resource request/limits for the container image | limits: "2" CPU, 4Gi, requests: 100m CPU, 128Mi | +| resources | The resource request/limits for the container image | limits: 500m CPU, 1Gi, requests: 100m CPU, 128Mi | | namespace | Namespace that this Helm chart is installed on. | `fleet-system` | -| logVerbosity | Log level. Uses V logs (klog) | `3` | +| logVerbosity | Log level. Uses V logs (klog) | `5` | | tlsClientInsecure | Skip TLS server certificate verification when the member agent connects to the hub cluster. Leave this `false` unless you explicitly trust the endpoint and understand the risk. | `false` | | useCAAuth | Use certificate-based authentication for the hub connection instead of the token-based path. | `false` | | propertyProvider | The property provider to use with the member agent; if none is specified, the Fleet member agent will start with no property provider (i.e., the agent will expose no cluster properties, and collect only limited resource usage information) | `` |