Skip to content

fix(deployd): force resynchronization of Application and Naisjob - #357

Closed
tronghn wants to merge 3 commits into
masterfrom
fix/deployd-force-resync-apps-jobs
Closed

fix(deployd): force resynchronization of Application and Naisjob#357
tronghn wants to merge 3 commits into
masterfrom
fix/deployd-force-resync-apps-jobs

Conversation

@tronghn

@tronghn tronghn commented Aug 5, 2026

Copy link
Copy Markdown
Contributor

Problem

Redeploying an Application or Naisjob with an unchanged spec hangs until timeout.

Cause

Both resources gained a status subresource in liberator
bacd0593. Previously, deployd's
update unintentionally cleared .status. Naiserator therefore always observed a
synchronization hash mismatch and reconciled the resource.

The API server now preserves .status during updates. For an unchanged spec, the stored
hash still matches, so Naiserator skips reconciliation without emitting the event
deployd is waiting for.

Naiserator's mitigation in
786b92a8 only handles resources in
RolloutComplete and reports completion without performing a new reconciliation.

Solution

Compare the resource generation before and after the update. When the generation is
unchanged, clear status.synchronizationHash through the status subresource. This forces
Naiserator to reconcile unchanged resources. Changed specs continue through the normal
reconciliation path without an additional status update.

Only the synchronization hash is cleared. Other operator-owned status fields remain
untouched.

This also lets resources in FailedSynchronization retry without requiring an
artificial spec change.

Ignore Naiserator's no-op rollout event while waiting because it describes the state
before the forced reconciliation, not its result.

tronghn added 3 commits August 5, 2026 11:19
Applications and Naisjobs gained a status subresource in liberator
bacd0593. Before that, deployd's update replaced the whole resource and
wiped .status, so Naiserator always found a hash mismatch and
synchronized. Now the API server keeps .status, an unchanged spec
matches the stored hash, and Naiserator skips synchronization without
emitting an event. The deployment then waits until it times out.

Clear the hash through the status subresource after writing the spec, so
every deployment resynchronizes regardless of spec changes. This also
unblocks resources stuck in FailedSynchronization, which persist their
hash and otherwise never reconcile again without a spec change.

Ignore Naiserator's no-op rollout event while waiting. It reports the
state from before the forced resynchronization, and accepting it would
report success without observing the rollout it triggers.
The envtest rig loads liberator CRDs that declare the status
subresource, so these cases reproduce the timeout that plain unit tests
cannot: an update no longer wipes .status, and only the deliberate patch
clears the synchronization hash.

Cover Naisjob as well, which had no coverage, and assert that the rest
of the status survives so the patch stays scoped to the one field.
@tronghn
tronghn force-pushed the fix/deployd-force-resync-apps-jobs branch from 265e671 to 3d895c3 Compare August 6, 2026 07:41
@tronghn

tronghn commented Aug 6, 2026

Copy link
Copy Markdown
Contributor Author

I think we can implement a more elegant fix in Naiserator actually. Closing this.

@tronghn tronghn closed this Aug 6, 2026
@tronghn
tronghn deleted the fix/deployd-force-resync-apps-jobs branch August 6, 2026 08:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant