Multi-stage cluster addons: Patching clusteraddon objects seems to cause issues

Open
#181 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Needs clarification
Activity status
Stale
Tech stack
go, kubernetes
Domain
infrastructure

Research direction

Start by tracing the clusteraddon object patching and the next reconcile loop during a create-then-upgrade flow, focusing on whether ready: true persists while conditions remain current. Done means the ready state is patched correctly and an upgrade flow is not triggered when no upgrade is necessary.

Written by the indexing model from the issue text.

Description

Container

/kind bug

What steps did you take and what happened:
Sometimes when testing it happens that an upgrade flow is triggered right after the create flow. This apparently has something to do with the "ready: true" not being patched correctly. At least in the next reconcile loop it is not there anymore. Or is this cached in the next reconcile loop? The conditions are up to date.

What did you expect to happen:
This should be patched correctly and we should not trigger upgrade flows if not necessary.

Dominant language
Go
Stars
18
Forks
5
No merged PRs in 30d

Contributor guide

Open the contributing guide

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 SovereignCloudStack/cluster-stack-operator

All issues in SovereignCloudStack/cluster-stack-operator

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.