Skip to content

Regular cleanup of orphaned resources for dashboard #1561

Open

Description

This comment by Gemini highlights a possible bug in the dashboard resources' reconciliation loop.

The concern that calling CleanupOrphanedResources() on every reconcile is expensive is valid. Although it is not expensive to list CozystackResourceDefinitions, since they are backed by the informer cache, this also triggers listing of dashboard custom resources, which are not backed by this cache.

The workaround of calling CleanupOrphanedResources() only on NotFound errors was implemented, but this opens the possibility of not cleaning up resources if the controller is down during a deletion. To fix this, some or all of the following should be implemented:

  • Owner references on dashboard custom resources should be enough to get cleaned up by the k8s garbage collector without waiting for an explicit CleanupOrphanedResources() call.
  • Finalizers on the CozystackResourceDefinition can help prevent an unhandled deletion event.
  • A ticker creating events at regular intervals to clean up orphaned resources will ensure eventual consistency.
  • An Owns()/Watches() on the owned resources in the SetupWithManager() method will make it less expensive to list these resources.

Activity

  1. added
    kind/bugCategorizes issue or PR as related to a bug
    on Oct 31, 2025
  2. dosubot commented on Jan 30, 2026

    @dosubot

    Hi, Timofei Larkin (@lllamnyp). I'm Dosu, and I'm helping the cozystack team manage their backlog and am marking this issue as stale.

    Issue Summary:

    • You identified a potential bug in the dashboard resources' reconciliation loop related to inefficient and unreliable cleanup of orphaned resources.
    • You suggested improvements such as using owner references for automatic garbage collection, adding finalizers, implementing periodic cleanup with a ticker, and optimizing resource watches.
    • There has been no further activity or comments on this issue since your initial report.

    Next Steps:

    • Please let me know if this issue is still relevant with the latest version of the cozystack repository by commenting here to keep the discussion open.
    • If I do not hear back within 7 days, this issue will be automatically closed.

    Thank you for your understanding and contribution!

  3. added
    lifecycle/staleDenotes an issue or PR has remained open with no activity and has become stale
    on Jan 30, 2026
  4. removed
    lifecycle/staleDenotes an issue or PR has remained open with no activity and has become stale
    on Feb 6, 2026
  5. github-actions commented on May 2, 2026

    @github-actions

    This issue has had no activity for 60 days and was marked lifecycle/stale.
    It will be closed in 14 days unless commented or labelled lifecycle/frozen.

  6. added
    lifecycle/staleDenotes an issue or PR has remained open with no activity and has become stale
    on May 2, 2026
  7. dosubot commented on Aug 1, 2026

    @dosubot

    Hi, Timofei Larkin (@lllamnyp). I'm Dosu, and I'm helping the cozystack team manage their backlog and am marking this issue as stale.

    Recap

    • CleanupOrphanedResources() was identified as too expensive to run on every reconcile because it lists dashboard custom resources outside the informer cache.
    • The current workaround is to run cleanup only on NotFound errors.
    • There is still concern that this approach can leave orphaned resources behind if the controller is down during deletion.
    • The issue proposed more reliable cleanup options such as owner references, finalizers, periodic cleanup ticks, and/or Owns()/Watches()-based reconciliation.

    Next Steps

    • Please let us know if this is still relevant on the latest version of the cozystack repository.
    • If it is still relevant, you can keep the discussion open by commenting here; otherwise, this issue will be automatically closed in 7 days.

    Thanks for your understanding and contribution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

kind/bugCategorizes issue or PR as related to a bugkind/featureCategorizes issue or PR as related to a new featurelifecycle/staleDenotes an issue or PR has remained open with no activity and has become staletriage/acceptedIndicates an issue is ready to be actively worked on

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions