Create DatacenterAware Integration tests with Multi Agent setup

[VictorCavichioli]

Story Description:
Create a TestClass using datacenterAware funcionality and run behave in parallel in both instances, one instance in dc1 and one instance in dc2, the jobs should be done respecting lock priority.

Acceptance Criteria:
Test class designed as expected and corner cases covered

Definition of Done:
Tests revised and approved by maintainers

Notes:

Related with #652

[0rlych1kk4]

Hi @VictorCavichioli
I recently contributed test improvements (#1374) and would be happy to help with additional test coverage around the DatacenterAware functionality.
Would it be useful if I take a look at specific scenarios or corner cases for the multi-agent setup?

Happy to coordinate to avoid overlap.

[VictorCavichioli]

Hi @0rlych1kk4 !

Thanks for your interest and sorry for the delay in the response,

I'm currently close to finish the first test scenario for DatacenterAware, which is Lock concurrency with on demand repair jobs, it would be really usefull to have the same scenario but for schedule jobs with a different repair interval!

I can describe what I'm thinking if you want to work on this

[0rlych1kk4]

Hi @VictorCavichioli thanks, that’s perfect. I can take the “same scenario but for scheduled jobs with a different repair interval” piece.
To make sure I align with what you’re already finishing for the on-demand case, can you point me to:

• the existing WIP test class / branch (or the main test file path) for the lock-concurrency + on-demand repair scenario
• where the scheduled repair interval is configured in the new framework (is it a YAML/test config knob, or set programmatically in the scenario builder?)
• what “different repair interval” you want to exercise (e.g., dc1=short interval, dc2=long interval, or same interval but shifted schedule)
  My plan: mirror your on-demand lock-concurrency flow, but swap the trigger to scheduled repairs and assert that (1) both agents progress in parallel across dc1/dc2, and (2) lock priority is respected when schedules overlap. I’ll also include at least one “overlap” corner case (schedule tick collision) to ensure it’s deterministic.

If you share what you’re thinking, I’ll start implementation and open a PR scoped only to this scheduled-jobs variant to avoid overlap. Once I have the pointers, I’ll aim to open a draft PR within the next couple of days so we can align early.