apache
HDDS-9824. Provide CLI that scans keys for a matching container and lists keys
What changes were proposed in this pull request?
HDDS-9824. Provide CLI that scans containers for keys
These changes are mostly quality of life improvements. There were use cases when it was necessary to check whether unhealthy container was empty. These changes help in that matter - this CLI outputs keys for input container ids (separated by comma).
How is this done? Everything was done on the client side, so there is no performance impact on the server side. RocksDB tables (keyTable, fileTable and dirTable) are read. KeyTable is pretty straightforward, it is read and container id is taken from OmKeyInfo. The situation is a little different for fileTable. In order to provide key name, fileTable and dirTable have to be read, and key name needs to be constructed, because FSO buckets does not follow the same ideology as non-FSO buckets in regards to key names.
Usage example: ozone debug ldb --db=/data/metadata/om.db ckscanner -ids=1,2,3
What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-9824
How was this patch tested?
Integration tests
@hemantk-12 @errose28 , thank you both for the review and comments. Unfortunately, I'm currently dealing with a health crisis and won't be able to address these until the start of next week. I'll do my best to handle everything as soon as I'm able to.
@hemantk-12 @errose28 thank you for the review once more. I addressed all the review comments and left some inline questions. Please, let me know what do you think.
Thanks @mladjan-gadzic for addressing previous review comment.
I left couple of questions and some cosmetic suggestions.
Also can you please add sample request and its output in the details? If there is any, you used for manual testing.
Thank you for the second review round. I will be sure to do that!
Thanks @mladjan-gadzic for working on this. I think this tool will be very useful.
Thank you for the review! Currently I am working on something else so I am going to put this PR in draft state, but I will be sure get back to this ASAP.
@mladjan-gadzic thanks for working on the patch , but a quick question, why we want to implement this as a CLI feature ? We already have it in recon UI.
As far as I know, complains about Recon UI that we got on this is that Recon is a little behind the real state in cluster even after refresh. Furthermore, AFAIK there is no way to check for a specific containers/keys, but UI output shows everything, and it can be hard to look through.
@mladjan-gadzic thanks for working on the patch , but a quick question, why we want to implement this as a CLI feature ? We already have it in recon UI.
As far as I know, complains about Recon UI that we got on this is that Recon is a little behind the real state in cluster even after refresh. Furthermore, AFAIK there is no way to check for a specific containers/keys, but UI output shows everything, and it can be hard to look through.
@mladjan-gadzic , Recon works on eventual consistency concept as it has periodic tasks to run , so there might be some delay,but you can search any container id in UI itself
@mladjan-gadzic thanks for working on the patch , but a quick question, why we want to implement this as a CLI feature ? We already have it in recon UI.
As far as I know, complains about Recon UI that we got on this is that Recon is a little behind the real state in cluster even after refresh. Furthermore, AFAIK there is no way to check for a specific containers/keys, but UI output shows everything, and it can be hard to look through.
@mladjan-gadzic , Recon works on eventual consistency concept as it has periodic tasks to run , so there might be some delay,but you can search any container id in UI itself
Could you please point me to that page/endpoint? As I can remember, issue was that there was pagination, and in order to get to a particular key we'd need to know on which page it is excatly if there is large number of keys.
@mladjan-gadzic thanks for working on the patch , but a quick question, why we want to implement this as a CLI feature ? We already have it in recon UI.
As far as I know, complains about Recon UI that we got on this is that Recon is a little behind the real state in cluster even after refresh. Furthermore, AFAIK there is no way to check for a specific containers/keys, but UI output shows everything, and it can be hard to look through.
@mladjan-gadzic , Recon works on eventual consistency concept as it has periodic tasks to run , so there might be some delay,but you can search any container id in UI itself
Could you please point me to that page/endpoint? As I can remember, issue was that there was pagination, and in order to get to a particular key we'd need to know on which page it is excatly if there is large number of keys.
Recon UI currently search across all pages in pagination is under development. But you can still use api/v1/containers/<container_id>/keys using curl command
I'm +1 for adding a CLI even if Recon has a similar feature. We've also seen instances where there are issues with Recon so it would be good to have a way to check OM RocksDB directly.
@mladjan-gadzic There are some merge conflicts, Can you rebase this PR with the latest master? We can work on getting this merged. Thank you for your contribution.
@mladjan-gadzic There are some merge conflicts, Can you rebase this PR with the latest master? We can work on getting this merged. Thank you for your contribution.
hi @aswinshakil! i am working on something else right now, and to be honest i've lost context on this so i'd need some time to get back to this. if time allows, i'd get back to it in the future, but i cannot promise anything.
Closing this for now in favor of HDDS-11747 since @sumitagrawl has started working on another implementation.