Support zero-downtime main InstallerSet upgrades

Open
  • Is something wrong?
#3,922 2 comments 1 reaction 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Quiet
Tech stack
go, kubernetes
Domain
infrastructure

Research direction

Start with MainSet and CleanupMainSet in pkg/reconciler/kubernetes/tektoninstallerset/client/main_set.go, then read TektonInstallerSet finalization in pkg/reconciler/kubernetes/tektoninstallerset/tektoninstallerset.go. Trace ErrVersionDifferent and the existing InstallerSet lifecycle before designing coexistence and readiness-gated retirement. Done means the listed coexistence, handoff, cleanup, idempotency, and resource-preservation cases are covered by tests.

Written by the indexing model from the issue text.

Description

kind/feature
Feature request

Main InstallerSet upgrades should use a readiness-gated handoff instead of deleting the current InstallerSets before creating their replacements.

Today, a release-version mismatch calls CleanupMainSet, and the old InstallerSet finalizers delete resources from the previous manifests before replacement sets are created:

This can temporarily remove shared ConfigMaps, RBAC, Services, APIService objects, and admission webhook configurations during an operator upgrade.

Implement a blue/green-style handoff for main InstallerSets:

  1. Keep the current generation while creating the desired-generation static and workload InstallerSets.
  2. Make replacement creation idempotent so reconciliation can resume after a partial failure.
  3. Wait for all desired-generation InstallerSets to report Ready.
  4. Retire only the explicitly identified old-generation InstallerSets.
  5. During old-generation finalization, preserve resources also represented by a non-deleting successor InstallerSet and delete only resources absent from every successor.
  6. Keep full cleanup when a component is removed and no successor exists.

The design should support the static/deployment split and the optional StatefulSet path without using broad CleanupMainSet selection during retirement.

Acceptance criteria:

  • Shared resources remain available until the desired generation is Ready.
  • Resources removed from the desired manifests are still pruned after a successful handoff.
  • Interrupted replacement creation resumes without producing duplicate sets.
  • Component deletion retains the existing cleanup behavior.
  • Tests cover generation coexistence, readiness-gated retirement, partial creation, shared-resource preservation, and obsolete-resource deletion.

Related work: #374 introduced InstallerSets for pruning resources removed by new releases, and #2121 guards reconciliation when a resource is already being deleted.

Use case

An operator upgrade changes the main InstallerSet release version while Tekton components continue serving requests. The old and desired generations share resources such as configuration, admission registration, RBAC, and Services. Those resources must remain present until the desired generation is healthy; otherwise the upgrade can create an admission or service-availability gap even though the resources will be recreated later.

Dominant language
Go
Stars
606
Forks
270
Avg merge
1d 7h
Merged PRs (30d)
159

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from tektoncd/operator

All issues in tektoncd/operator

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.