Fix MedusaTask to delete only its own backups

[dnugmanov]

What this PR does: This commit addresses the issue where MedusaTask was erroneously deleting medusabackups belonging to other cassandraDatacenters in the same namespace. The bug occurred due to the lack of a condition to check if the backup.Spec.CassandraDatacenter matched the task.Spec.CassandraDatacenter. This fix adds the necessary condition to ensure that MedusaTask only deletes its own Cassandra backups, resolving the issue reported in the PR.

Which issue(s) this PR fixes:
Fixes #1017

Checklist

• Changes manually tested
• Automated Tests added/updated
• Documentation added/updated
• CHANGELOG.md updated (not required for documentation PRs)
• CLA Signed: DataStax CLA

[codecov]

Codecov Report

Merging #1025 (5ad0143) into main (4e2cd71) will decrease coverage by 0.01%.
The diff coverage is 0.00%.

❗ Current head 5ad0143 differs from pull request most recent head 70821b1. Consider uploading reports for the commit 70821b1 to get more accurate results

@@            Coverage Diff             @@
##             main    #1025      +/-   ##
==========================================
- Coverage   57.49%   57.48%   -0.01%     
==========================================
  Files          99       99              
  Lines       10011    10011              
==========================================
- Hits         5756     5755       -1     
  Misses       3764     3764              
- Partials      491      492       +1     

Files Changed	Coverage Δ
controllers/medusa/medusatask_controller.go	48.12% <0.00%> (+0.34%)	⬆️

... and 3 files with indirect coverage changes

[burmanm]

Hey, thanks for the PR. What I'd really like to see on this one is a test, to ensure that the functionality actually does fix the issue (so a test which would fail without the fix and passes with the fix in place). e2e test isn't necessary, unit / integration test (envtest) is perfectly fine.

The issue in reality comes from the fact that the Pod's fetched backups do not match the localBackup search. Even with just comparing Datacenters we're really comparing the Task's Datacenter vs. whatever the Pod believes is the correct Datacenter. This is not necessarily the same thing, due to the ability to override the Datacenter. In that case, the task will have a Datacenter name that's not recognized by the Pod's Datacenter.

@adejanovski I think the above issue plagues any user who uses DatacenterName overrides in cass-operator. Doesn't the Pod backup store the Cassandra's real Datacenter name instead of the CassandraDatacenter.Name? If so, we need to fetch the original CassandraDatacenter and use its DatacenterName() for comparison.

[burmanm]

Alright, the Datacenter name is fine. So the only thing to add would be the tests that verify the correct behavior.

[dnugmanov]

Hello, @burmanm! I've implemented an integration test for the following scenarios:

1. Create a multi-datacenter K8ssandra cluster.
2. Generate backups for each datacenter (dc).
3. Purge backups for dc1.
4. Verify that backups for dc2 still exist.

The final condition will pass the test only if we verify that backup.Spec.CassandraDatacenter is identical to task.Spec.CassandraDatacenter. Otherwise, the sync task may unintentionally delete backup4 for dc2.

If you have the time, please take a look at the PR and let me know your thoughts. Your feedback is much appreciated, and if there's anything that needs further rephrasing or improvement, feel free to point it out. Thank you for your help!

[burmanm]

This will need a rebase for the changelog file.

[sonarcloud]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
1 Code Smell

No Coverage information
17.2% Duplication

Catch issues before they fail your Quality Gate with our IDE extension SonarLint

[dnugmanov]

This will need a rebase for the changelog file.

Done

[burmanm]

Thank you for the PR.