Skip to content

Investigate if all state associated with a given resource could be managed in a single spot #1314

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
metacosm opened this issue Jul 4, 2022 · 1 comment
Milestone

Comments

@metacosm
Copy link
Collaborator

metacosm commented Jul 4, 2022

Candidate states to be unified: retry, event marker, rate limiting…
The most likely spot would be EventProcessor.

Pros:

  • state is managed in a single spot and EventProcessor knows when the state needs to be modified / cleaned-up
  • would simplify moving to a multi-cluster model since how resource state is tracked would be more localised instead of spread in different spots

Cons:

  • probably needs to abstract state in a generic way
@csviri
Copy link
Collaborator

csviri commented Jul 4, 2022

state is managed in a single spot and EventProcessor knows when the state needs to be modified / cleaned-up

Now this would help probably just with the cleanup. Also in the background we won't use 3 HashMaps just 1.

probably needs to abstract state in a generic way

Yes, this would mean rate limiter needs a spefic api for execution state, separated, what is not nice, since this does not fit well to the rate limiter API.

Something similar would hold for event marker. That is not exposed, so would not be such an issue.

@csviri csviri added this to the 3.1 milestone Jul 13, 2022
@csviri csviri closed this as completed Jul 13, 2022
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

No branches or pull requests

2 participants