HAProxy skips the wait when drain=true and the backend is down - fix issue 8092

[BachenbergS]

SUMMARY

Fixes #8092

My fix ensures that HAProxy skips the wait when drain=true and the backend is down.

Details:

• The fix addresses an issue where HAProxy could get stuck in DRAIN mode when the backend was unreachable.
• The fix instructs HAProxy to skip waiting for active connections if the backend is down.
• This results in faster and more reliable failover times.

Benefits:

• Improved performance and reliability during failover
• Avoidance of getting stuck in DRAIN mode
• Reduced downtime

ISSUE TYPE

• Bugfix Pull Request

COMPONENT NAME

haproxy

ADDITIONAL INFORMATION

[ansibullbot]

cc @Normo @ravibhure click here for bot help

[BachenbergS]

I moved my fix two lines down. This ensures that the backend is still set to DRAIN and only the wait is skipped. If the backend is set to DRAIN and the server is unreachable, it will remain in the DOWN state. However, if it comes back up during this time, it will switch to DRAIN. Otherwise, it would go back to UP in the worst case.

[webknjaz]

@RayJin2000 did you use ChatGPT or any other LLM to generate the description?

[russoz]

Hi @RayJin2000

Thank you for the contribution! Please add a changelog fragment.

[BachenbergS]

@RayJin2000 did you use ChatGPT or any other LLM to generate the description?

Yes, that helps a lot if your not a native speaker.

Thanks for your contribution. Could you please add a changelog fragment? Thanks.

Regarding the change: this directly contradicts the description of the wait parameter's description. So this would be a breaking change, since some users might rely on the current behavior.

It might be better to instead make the behavior configurable, i.e. to tell the module to only wait in specific circumstances. I don't think that this change is a good idea.

The documentation of drain says:

Wait until the server has no active connections or until the timeout determined by wait_interval and wait_retries is reached. Continue only after the status changes to MAINT.

If a backend is DOWN, it has no active connections. So why should we wait for the Timeout? The Backend will never enter the state of DRAIN, but the Task will continue only after the status changes to MAINT.

If you mean this part of the documentation:

Wait until the server reports a status of UP when state=enabled, status of MAINT when state=disabled or status of DRAIN when state=drain.

My Fix changes only the behavior of the workflow state=disabled . If the desired state is DRAIN everything behaves like before my fix.

[ansibullbot]

@RayJin2000 this PR contains the following merge commits:

• https://github.com/ansible-collections/community.general/commit/ae2ffab149538aedba3e336ae5e92bf242c2b8b3

Please rebase your branch to remove these commits.

click here for bot help

[ansibullbot]

@RayJin2000 this PR contains the following merge commits:

• https://github.com/ansible-collections/community.general/commit/ae2ffab149538aedba3e336ae5e92bf242c2b8b3
• https://github.com/ansible-collections/community.general/commit/109d5422a35e009d01222945cf92684355691948

Please rebase your branch to remove these commits.

click here for bot help

[ansibullbot]

@RayJin2000 this PR contains the following merge commits:

• https://github.com/ansible-collections/community.general/commit/ae2ffab149538aedba3e336ae5e92bf242c2b8b3
• https://github.com/ansible-collections/community.general/commit/109d5422a35e009d01222945cf92684355691948
• https://github.com/ansible-collections/community.general/commit/027aafc6ed99ef050bfc4954f1612efbc01769bb

Please rebase your branch to remove these commits.

click here for bot help

[BachenbergS]

Sorry for all the latest commits. I accidentally hit the "sync fork" Button in Github.

ready_for_review

[ansibullbot]

@RayJin2000 this PR contains the following merge commits:

• https://github.com/ansible-collections/community.general/commit/ae2ffab149538aedba3e336ae5e92bf242c2b8b3
• https://github.com/ansible-collections/community.general/commit/109d5422a35e009d01222945cf92684355691948
• https://github.com/ansible-collections/community.general/commit/027aafc6ed99ef050bfc4954f1612efbc01769bb
• https://github.com/ansible-collections/community.general/commit/e62f940a5f6ee6f844cfce2c548d1f7b5779a0f1

Please rebase your branch to remove these commits.

click here for bot help

[BachenbergS]

@RayJin2000 this PR contains the following merge commits:

* [ae2ffab](https://github.com/ansible-collections/community.general/commit/ae2ffab149538aedba3e336ae5e92bf242c2b8b3)

* [109d542](https://github.com/ansible-collections/community.general/commit/109d5422a35e009d01222945cf92684355691948)

* [027aafc](https://github.com/ansible-collections/community.general/commit/027aafc6ed99ef050bfc4954f1612efbc01769bb)

* [e62f940](https://github.com/ansible-collections/community.general/commit/e62f940a5f6ee6f844cfce2c548d1f7b5779a0f1)

Please rebase your branch to remove these commits.

click here for bot help

Can someone help me. This gets bigger with every Rebase.

[felixfontein]

It seems you have now successfully rebased the merge commits away.

[patchback[bot]]

Backport to stable-7: 💚 backport PR created

✅ Backport PR branch: patchback/backports/stable-7/b2b8fc30bf9bbccb8cab06a21833d2d7a179435b/pr-8100

Backported as https://github.com/ansible-collections/community.general/pull/8156

🤖 @patchback I'm built with octomachinery and my source is open — https://github.com/sanitizers/patchback-github-app.

[patchback[bot]]

Backport to stable-8: 💚 backport PR created

✅ Backport PR branch: patchback/backports/stable-8/b2b8fc30bf9bbccb8cab06a21833d2d7a179435b/pr-8100

Backported as https://github.com/ansible-collections/community.general/pull/8157

🤖 @patchback I'm built with octomachinery and my source is open — https://github.com/sanitizers/patchback-github-app.

[felixfontein]

@RayJin2000 thanks for your contribution! @webknjaz @russoz @bcoca thanks for reviewing!