After a Helm rename, 46 old Azure DevOps releases could still redeploy the retired path

While the old release still held the host and path, the admission webhook refused the new release's duplicate ingress, according to the author's first-person account on devops.com ^[9]. The refusal came late. Helm had already created a Secret, a ServiceAccount, a Service and a Deployment, and because the task used neither --atomic nor --cleanup-on-fail, all four stayed in the cluster ^[9]. That happened during the forward rename. The author never ran a stale release, and describes the stale-redeploy path as conditional, based on that failure order ^[10].

The old releases would follow the same sequence. Their stored task called Helm with --install against a release name that no longer existed, and Helm documents that flag as an instruction to install when it cannot find the name ^[8]. A redeploy would therefore attempt a second installation under the retired identity ^[8]. The cutover had changed four coupled values together: the image repository path, the packaged chart name, the Helm release name and the Kubernetes resource names ^[7]. The current definition showed only the replacements ^[7].

The habit is to treat the release definition as the pipeline. The author tested how far a release's snapshot reaches: changing a linked variable group did not change an existing Classic release, and only a newly created release picked up the new values ^[11].

The first containment step was deleting the retired image repositories, once no active workload or current pipeline referenced them ^[13]. After that, a stale deploy could still create objects, but its pod could not pull the old image and would sit in ImagePullBackOff ^[13]. The author checked current releases and workloads before deleting anything ^[14]. Finding the stale releases took the Release API, filtering each definition by active status and maximum creation time ^[15]. The cutover timestamp only produced candidates. Each release's stored task decided whether it was stale ^[15].

In my view a Classic migration is finished when no active release holds a stored task that names a retired value. The tradeoff is rollback. Deleting the retired repositories removed image-level rollback through the old path, and an abandoned release is one fewer way back to the old configuration ^[14]. Sort each old release by two tests: whether its stored task references any retired name or path, and whether the image it points to can still be pulled.

- Retired task, pullable image: a redeploy could start pods whose usefulness depends on the old image and the values captured at creation ^[12]. Abandon these first. - Retired task, image deleted: a redeploy ends in ImagePullBackOff with orphaned objects ^[13]. Abandon them, then clean up what they left. - Current task, pullable image: an ordinary release and a working rollback. Keep it. - Current task, image deleted: a repository still in use was removed, the case the author checked for before deleting ^[14]. Restore it before retiring anything else.