# Redis 27.0.0 default pilot run A live pilot snapshot from the Redis 25.5.3 to 27.0.0 upgrade test for the default lane. Start here when you open this Space in Hub. This page explains the problem this example is meant to show, what to inspect, why it matters, and where the evidence lives. ## Why this example exists This example makes the pilot concrete. It is easier to trust the story when the actual run has a place in the org. The lesson is practical: keep the Helm chart, but record the change so an upgrade does not depend on remembering the right flag. ## What this example shows - The chart upgrade was tested against a real throwaway cluster. - The important question was whether a local operations edit survived the chart upgrade. - The result was recorded so someone can inspect the run later instead of trusting a demo claim. ## Where each setting comes from | Place | What this Space records | | --- | --- | | Starting configuration | Open the upstream Space or source link named on this page. That is the configuration this Space started from. | | ConfigHub changes | Open Unit revision history. It records changes made after the starting configuration was saved. | | Install work | Use the linked chart or route evidence for required Secrets, CRDs, hooks, setup jobs, and target facts. | | Live cluster | Use target observations to compare the cluster with the reviewed Units. A live-only edit is drift until it is recorded or removed. | If an upstream change and a local ConfigHub revision touch the same field, review the overlap before promotion. ## What to inspect in Hub - This README. - Redis workload YAML. - Revision history for the changed YAML. ## Evidence and source - [Benchmark: upgrade keeps edit](https://github.com/confighub/helm-expt/blob/main/data/pilot-benchmark/task1-upgrade-keeps-edit.md) ## Limits - This is a dated pilot snapshot from 2026-07-05.