Skip to content
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.

Sign up for GitHub

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

Jump to bottom

lmplement the cluster logic #30

Open
sparshev opened this issue Oct 31, 2022 · 2 comments
Open

lmplement the cluster logic #30

sparshev opened this issue Oct 31, 2022 · 2 comments
Assignees
@sparshev
Labels
enhancement New feature or request
Milestone
v1.0.0

Comments

@sparshev
Copy link
Collaborator

After #1 we've lost DQlite-based cluster formation and left with a basic implementation of the websocket-based protocol. So need to complete it to allow cluster of the nodes to work as one - what could be easier?)
@sparshev sparshev added the enhancement New feature or request label Oct 31, 2022
@sparshev sparshev self-assigned this Oct 31, 2022
@sparshev sparshev mentioned this issue Oct 31, 2022
Closed
@sparshev sparshev added this to the v1.0.0 milestone Feb 18, 2023
@sparshev sparshev mentioned this issue Apr 11, 2023
Merged
10 tasks
sparshev added a commit that referenced this issue Apr 11, 2023
@sparshev
YAML support, Maintenance/Shutdown API and updated dependencies (#49)
b9cf5c9 
This change is for improving the general usability:
* Added yaml support to all API requests to improve user quality of life - storing labels in YAML is much easier than json, json interface is still supported
* Added maintenance / shutdown API - to allow user to request graceful shutdown of the node, will be really useful in the loaded cluster #30
* Updated the dependencies - there was a number of updated deps which needed the updates
* Cleaned up the logic a bit
@sparshev sparshev mentioned this issue May 30, 2023
Open
10 tasks
@sparshev
Copy link
Collaborator Author

sparshev commented Aug 4, 2023

Hmmm... Thought about the cluster sync and it looks like we should not sync everything but only the necessary things. Like everything except for Applications and Votes for example for each new connection. Currently the implementation syncs only when the node is starting up, which limits the node sync after connection broken. But if we will sync only the needed things every time when connection established - this way we will have free brainsplit restoration and not that complicated logic with the update time of the cluster...

So need to think about that more... For sure will need to optimize the object storage (to not write the same objects again and again) and allow the logic to receive not existing objects from the cluster in runtime, but could worth a shot. Otherwise I don't see how to make the cluster in sync properly.

@sparshev
Copy link
Collaborator Author

Votes, actually, doesn't need to be stored forever - so I think we can easily remove them entirely from the DB (preventing bloat-up with not needed info) and store votes only during runtime for each NEW Application. This will need a major rewrite of the election process - which is actually good, because allow to move from pool-based to event based processing, that should improve the performance of Application processing significantly.

@sparshev sparshev mentioned this issue Dec 6, 2023
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@sparshev sparshev

Labels
enhancement New feature or request
Projects
None yet
Milestone
v1.0.0
Development

No branches or pull requests
1 participant
@sparshev