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
Table-Manager: Create/Update table before deleting tables #3055
Comments
This issue has been automatically marked as stale because it has not had any activity in the past 60 days. It will be closed in 15 days if no further activity occurs. Thank you for your contributions. |
Still valid |
This issue has been automatically marked as stale because it has not had any activity in the past 60 days. It will be closed in 15 days if no further activity occurs. Thank you for your contributions. |
Still valid, help wanted! |
Hello, I was looking to getting involved with the project. Can I work on this? |
Hi @daemon1024 none is working on this issue. If you're a Cortex user, I would suggest you to start from an issue you will directly benefit from. For example, the table-manager is used only by the chunks storage, and a good amount of Cortex users (including my employer) are moving or already moved to the blocks storage, so if you're not running the chunks storage I would suggest you to take a look at the blocks storage issues, which is the direction where the community is heading to. |
Hi @pracucci , I am not a Cortex user, I am a student looking to get involved with CNCF in general this seemed like an interesting project hence looking into the |
Closing this since chunks storage is now in maintenance mode. |
cortex/pkg/chunk/table_manager.go
Lines 340 to 350 in e2a36a7
When the table manager actually attempts to sync and operate on the chunk storage backend it will proceed in the following order:
If any of these operations fail at any point, the entire sync will return. This can lead to issues for users who have delete operations that are unsuccessful, since new tables will not be created. This means new data will not be flushed since no table exists to support it. I propose the following order:
This order will prioritize write availability over storage retention.
The text was updated successfully, but these errors were encountered: