Introduce a compensating workflow that launches the dedicated AWX
rollback template when a deployment cannot be started or fails midway.
- add task states: rollback_pending, rolling_back, rolled_back,
rollback_failed, rollback_acknowledged
- add RollbackJob model to track the compensating AWX run separately
from the deploy run, preserving both job IDs for audit
- hold resource reservations in 'rollback' status until cleanup
succeeds so a failed cleanup cannot be masked by a later delivery
- poll rollback jobs with a 2-minute launch timeout; an unknown launch
result surfaces as a recoverable failure instead of re-launching
- protect finished/register_failed/rolled-back tasks from rollback;
register_failed keeps the healthy instance and its resource usage
- add DELIVERY_ROLLBACK_TEMPLATE_ID config; without it, failures are
marked rollback_failed and require manual cleanup
- use unique pending-<task_id> placeholder for executor job IDs
- Per-host instance limit (DELIVERY_HOST_INSTANCE_LIMIT, default 4)
- Optional target_host to pin a host from the candidate pool
- Regenerate swagger docs
- Add topology/port/data_disk, DB options and 8 advanced parameters
with whitelist validation, rendered via extra_vars into the playbook
- Hybrid port allocation over pool 13306-13999
- Tighten bounds: memory 2048-65536 MiB, storage 20-2000 GiB
l x
Gmarker689