-
Notifications
You must be signed in to change notification settings - Fork 52
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
Add cli-flag to keep db after changing assignments #280
Conversation
Master coverage: 70.97% |
One of the warp sync tests is failing because it seems the container chain db for |
That was because it was panicking on this line: I pushed a commit fixing that by using a different kind of channel to signal shutdown, now we can distinguish between "stopping because someone called .stop()" and "stopping because the node process is stopping". We will only delete the db in the first case. |
@tmpolaczyk thank you so much for the clarification! I was hesitating if that piece of code was in the correct place. |
node/src/container_chain_spawner.rs
Outdated
.latest_block_number(orchestrator_chain_info.best_hash, container_chain_para_id) | ||
.unwrap_or_default(); | ||
|
||
let max_block_diff_allowed = 10u32; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let max_block_diff_allowed = 10u32; | |
let max_block_diff_allowed = 100u32; |
node/src/container_chain_spawner.rs
Outdated
@@ -226,7 +254,7 @@ impl ContainerChainSpawner { | |||
container_chain_cli_config.database.set_path(&db_path); | |||
|
|||
// Delete existing database if running as collator | |||
if validator { | |||
if validator && !container_chain_cli.base.keep_db && warp_sync { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am hesitating about this. What happens if:
- I have the keep_db flag to true
- but I detect that the genesis-hash of the chain-spec I am running is different (genesis-hash different)
- in that case I would be stuck (the node tells me to reboot and that I need to use warp sync, all the time, but I need all these 3 flags to be true to delete the db and hence be able to do warp sync)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should immediatly delete the container-chain-db if the spec is differnt I believe
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there is no reason to maintain a DB that does not match with the specs right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right
I like the way it looks now, we can unitest the delete db cases quite easily! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
self-approving
This PR adds a simple
keep_db
flag toContainerChainRunCmd
struct that allows to keep container-chain databases after changing collator assignments.