Implement Zookeeper schema handler #129

Closed
opened 2021-06-08 00:59:27 -04:00 by JoshuaBoniface · 15 comments
JoshuaBoniface commented 2021-06-08 00:59:27 -04:00 (Migrated from git.bonifacelabs.ca)

Currently any changes to Zookeeper schema is done ad-hoc and in code. This is hard to maintain and makes changing key paths, using prefixes, etc. impossible.

Implement several helpers for this:

  1. Implement a schema handler, that can contain schema definitions of various classes. These could then be used by class instances.

  2. Implement a schema migration system to allow upgrade and downgrade of schemas similar in conception to SQLAlchemy.

  3. Implement conditional triggering of schema changes, such that a cluster can be upgraded seamlessly to a new version and then trigger application of changes afterwards. This may be tricky and might need to leverage a way to restart a daemon without transferring primary control so the daemon can clearly refresh, or a way to do this in-code.

Currently any changes to Zookeeper schema is done ad-hoc and in code. This is hard to maintain and makes changing key paths, using prefixes, etc. impossible. Implement several helpers for this: 1. Implement a schema handler, that can contain schema definitions of various classes. These could then be used by class instances. 2. Implement a schema migration system to allow upgrade and downgrade of schemas similar in conception to SQLAlchemy. 3. Implement conditional triggering of schema changes, such that a cluster can be upgraded seamlessly to a new version and then trigger application of changes afterwards. This may be tricky and might need to leverage a way to restart a daemon without transferring primary control so the daemon can clearly refresh, or a way to do this in-code.
JoshuaBoniface commented 2021-06-08 01:00:33 -04:00 (Migrated from git.bonifacelabs.ca)

This can likely just be a component of the updated zkhandler definitions in daemon-common.

This can likely just be a component of the updated `zkhandler` definitions in `daemon-common`.
JoshuaBoniface commented 2021-06-08 21:36:04 -04:00 (Migrated from git.bonifacelabs.ca)

mentioned in commit a78d4b273773a27c46de19c7951694453b4e3a86

mentioned in commit a78d4b273773a27c46de19c7951694453b4e3a86
JoshuaBoniface commented 2021-06-08 22:20:37 -04:00 (Migrated from git.bonifacelabs.ca)

mentioned in commit ff32a2a5a0e85a04735980e5fd9aad32bb30f5d9

mentioned in commit ff32a2a5a0e85a04735980e5fd9aad32bb30f5d9
JoshuaBoniface commented 2021-06-08 22:20:37 -04:00 (Migrated from git.bonifacelabs.ca)

mentioned in commit 36d424d212cdf7a8a1863b9128bb4965c41754d6

mentioned in commit 36d424d212cdf7a8a1863b9128bb4965c41754d6
JoshuaBoniface commented 2021-06-08 22:22:47 -04:00 (Migrated from git.bonifacelabs.ca)

Initial implementation completed, and node daemon set to validate schema on startup.

Still deciding how to proceed with migrations, either to do so in Daemon or API. API seems more reasonable, since it can potentially be made to query nodes as to what schema version they run.

Initial implementation completed, and node daemon set to validate schema on startup. Still deciding how to proceed with migrations, either to do so in Daemon or API. API seems more reasonable, since it can potentially be made to query nodes as to what schema version they run.
JoshuaBoniface commented 2021-06-08 22:32:05 -04:00 (Migrated from git.bonifacelabs.ca)

mentioned in commit cbd46ecf67e62db7fac4505cd05ee5d1644b153f

mentioned in commit cbd46ecf67e62db7fac4505cd05ee5d1644b153f
JoshuaBoniface commented 2021-06-08 22:35:51 -04:00 (Migrated from git.bonifacelabs.ca)

mentioned in commit 4899c1aae68ff4a561020c7b5a37e0e68cd28059

mentioned in commit 4899c1aae68ff4a561020c7b5a37e0e68cd28059
JoshuaBoniface commented 2021-06-08 23:22:09 -04:00 (Migrated from git.bonifacelabs.ca)

Decided instead to do it in the nodes, because that's where it makes the most sense. They can now keep track of their own active and latest versions, and when the last is upgraded, fire a full upgrade.

Decided instead to do it in the nodes, because that's where it makes the most sense. They can now keep track of their own active and latest versions, and when the last is upgraded, fire a full upgrade.
JoshuaBoniface commented 2021-06-08 23:35:56 -04:00 (Migrated from git.bonifacelabs.ca)

mentioned in commit 126f0742cd

mentioned in commit 126f0742cd1b4e3d6572313fccdb1c95d9baf907
JoshuaBoniface commented 2021-06-08 23:35:56 -04:00 (Migrated from git.bonifacelabs.ca)

mentioned in commit 602dd7b714

mentioned in commit 602dd7b71450959b1ee39f569673909cad5298da
JoshuaBoniface commented 2021-06-08 23:35:57 -04:00 (Migrated from git.bonifacelabs.ca)

mentioned in commit a4aaf89681

mentioned in commit a4aaf89681ce2166978d29e5382b9a8ddf686166
JoshuaBoniface commented 2021-06-08 23:35:57 -04:00 (Migrated from git.bonifacelabs.ca)

mentioned in commit 3c102b3769

mentioned in commit 3c102b3769b269a6dcbf0875b4c21daa0271c8c0
JoshuaBoniface commented 2021-06-08 23:35:57 -04:00 (Migrated from git.bonifacelabs.ca)

mentioned in commit 5540bdc86b

mentioned in commit 5540bdc86b78155b9636f7d5354c14c0b28cc2fa
JoshuaBoniface commented 2021-06-17 01:49:10 -04:00 (Migrated from git.bonifacelabs.ca)

Final implementation completed in PVC 0.9.20.

Final implementation completed in PVC 0.9.20.
JoshuaBoniface commented 2021-06-17 01:49:11 -04:00 (Migrated from git.bonifacelabs.ca)

closed

closed
Sign in to join this conversation.
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: parallelvirtualcluster/pvc#129
No description provided.