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.

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

Scale up scale down can break contorl plane metastore consistency. #5013

Closed
fulmicoton opened this issue May 21, 2024 · 0 comments · Fixed by #5029
Closed

Scale up scale down can break contorl plane metastore consistency. #5013

fulmicoton opened this issue May 21, 2024 · 0 comments · Fixed by #5029
Assignees
Labels
bug Something isn't working

Comments

@fulmicoton
Copy link
Contributor

fulmicoton commented May 21, 2024

(Today we ignore metastore error)

@fulmicoton fulmicoton added the bug Something isn't working label May 21, 2024
@fulmicoton fulmicoton self-assigned this May 21, 2024
fulmicoton added a commit that referenced this issue May 26, 2024
On scale up, rebalance, and get_or_open_shards, the control plane was:
- recording a shard on the metastore
- writing the shard
- record the shard on the control plane model.

Error handling was not done, so a transport failure on the metastore, or
(more likely) an error failure on init would break consistency between
the metastore and the control plane.

This PR factorizes the idea of opening a new shard for scale up,
rebalance and get_or_open_shards.

The new factorize logic goes:
- init first
- record in the metastore
- record the shard on the control plane model.

The last two steps are also factorized together to emphasize that we
keep the control plane and metastore in sync.

It works by forcing a restart of the control plane if the metastore
returns an error for which we don't know if the write was a success or
not.

Closes #5008
Closes #5020
Closes #5013

test compilation
fulmicoton added a commit that referenced this issue May 26, 2024
On scale up, rebalance, and get_or_open_shards, the control plane was:
- recording a shard on the metastore
- writing the shard
- record the shard on the control plane model.

Error handling was not done, so a transport failure on the metastore, or
(more likely) an error failure on init would break consistency between
the metastore and the control plane.

This PR factorizes the idea of opening a new shard for scale up,
rebalance and get_or_open_shards.

The new factorize logic goes:
- init first
- record in the metastore
- record the shard on the control plane model.

The last two steps are also factorized together to emphasize that we
keep the control plane and metastore in sync.

It works by forcing a restart of the control plane if the metastore
returns an error for which we don't know if the write was a success or
not.

Closes #5008
Closes #5020
Closes #5013
fulmicoton added a commit that referenced this issue May 26, 2024
On scale up, rebalance, and get_or_open_shards, the control plane was:
- recording a shard on the metastore
- writing the shard
- record the shard on the control plane model.

Error handling was not done, so a transport failure on the metastore, or
(more likely) an error failure on init would break consistency between
the metastore and the control plane.

This PR factorizes the idea of opening a new shard for scale up,
rebalance and get_or_open_shards.

The new factorize logic goes:
- init first
- record in the metastore
- record the shard on the control plane model.

The last two steps are also factorized together to emphasize that we
keep the control plane and metastore in sync.

It works by forcing a restart of the control plane if the metastore
returns an error for which we don't know if the write was a success or
not.

Closes #5008
Closes #5020
Closes #5013
fulmicoton added a commit that referenced this issue May 26, 2024
On scale up, rebalance, and get_or_open_shards, the control plane was:
- recording a shard on the metastore
- writing the shard
- record the shard on the control plane model.

Error handling was not done, so a transport failure on the metastore, or
(more likely) an error failure on init would break consistency between
the metastore and the control plane.

This PR factorizes the idea of opening a new shard for scale up,
rebalance and get_or_open_shards.

The new factorize logic goes:
- init first
- record in the metastore
- record the shard on the control plane model.

The last two steps are also factorized together to emphasize that we
keep the control plane and metastore in sync.

It works by forcing a restart of the control plane if the metastore
returns an error for which we don't know if the write was a success or
not.

Closes #5008
Closes #5020
Closes #5013
fulmicoton added a commit that referenced this issue May 26, 2024
On scale up, rebalance, and get_or_open_shards, the control plane was:
- recording a shard on the metastore
- writing the shard
- record the shard on the control plane model.

Error handling was not done, so a transport failure on the metastore, or
(more likely) an error failure on init would break consistency between
the metastore and the control plane.

This PR factorizes the idea of opening a new shard for scale up,
rebalance and get_or_open_shards.

The new factorize logic goes:
- init first
- record in the metastore
- record the shard on the control plane model.

The last two steps are also factorized together to emphasize that we
keep the control plane and metastore in sync.

It works by forcing a restart of the control plane if the metastore
returns an error for which we don't know if the write was a success or
not.

Closes #5008
Closes #5020
Closes #5013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant