Users sometimes bypass Flint SQL and delete Flint data indexes directly in OpenSearch using the REST endpoint. This can lead to inconsistencies and errors, as Flint is not aware of these deletions, and crucial metadata is not updated, disrupting features like index acceleration and query rewrites.
What solution would you like?
I propose implementing a way to enforce the use of Flint SQL statements (e.g., DROP and VACUUM index) for index management. This could involve disabling direct index deletions via OpenSearch REST, or issuing warnings and logs when Flint indexes are deleted outside of Flint SQL, ensuring that metadata remains consistent.
Technical Challenges:
Differentiating Delete REST Requests: The VACUUM index statement also uses the REST endpoint to delete indexes, so we need a method to distinguish between legitimate Flint system requests and direct user requests via the REST endpoint.
Intercepting REST Requests: We would need to find a way to intercept the delete REST requests from users and either inject warnings or enforce cascading delete logic to ensure metadata consistency.
What alternatives have you considered?
Adding documentation to warn users against direct deletions, though this can be easily ignored or overlooked.
Detect and reconcile direct deletions, but this is a reactive solution than proactive, as seen in OpenSearch Spark Issue #356.
Is your feature request related to a problem?
Users sometimes bypass Flint SQL and delete Flint data indexes directly in OpenSearch using the REST endpoint. This can lead to inconsistencies and errors, as Flint is not aware of these deletions, and crucial metadata is not updated, disrupting features like index acceleration and query rewrites.
What solution would you like?
I propose implementing a way to enforce the use of Flint SQL statements (e.g.,
DROPandVACUUMindex) for index management. This could involve disabling direct index deletions via OpenSearch REST, or issuing warnings and logs when Flint indexes are deleted outside of Flint SQL, ensuring that metadata remains consistent.Technical Challenges:
VACUUMindex statement also uses the REST endpoint to delete indexes, so we need a method to distinguish between legitimate Flint system requests and direct user requests via the REST endpoint.What alternatives have you considered?
Do you have any additional context?
N/A