added FIP Cooldown before start

docs/USAGE.md

@@ -21,6 +21,7 @@
 - [Повторная проверка адреса](#повторная-проверка-адреса)
 - [Принудительная остановка проверки](#принудительная-остановка-проверки)
 - [Удаление адресов из очереди](#удаление-адресов-из-очереди)
+- [Пауза перед self-check (fip_settle_seconds)](#пауза-перед-self-check-fip_settle_seconds)
 - [Частые проблемы и что с ними делать](#частые-проблемы-и-что-с-ними-делать)
 
 ## Как устроена работа с системой
@@ -413,6 +414,36 @@ curl -s -X POST http://<control-api>:8080/api/v1/admin/ips/clear
 всё» — каждая с подтверждением, явно предупреждающим о необратимости
 (см. [DASHBOARD.md](DASHBOARD.md)).
 
+## Пауза перед self-check (fip_settle_seconds)
+
+Как только Floating IP привязывается к валидатору, control-api по
+умолчанию сразу же позволяет агенту начать self-check — а data plane
+OpenStack может не успеть в этот же момент реально начать пропускать
+трафик через только что привязанный адрес, из-за чего self-check ложно
+проваливается по причине, не связанной с самой привязкой. Если это
+наблюдается на вашем стенде, задайте паузу между привязкой FIP и началом
+self-check:
+
+```bash
+curl -s -X PUT http://<control-api>:8080/api/v1/admin/config/orchestrator \
+  -d '{"fip_settle_seconds": 5}'
+```
+
+То же самое — на странице `/settings` дашборда. `0` (по умолчанию) — без
+паузы. Пока пауза не истекла, адрес уже в состоянии
+`awaiting_self_check`, но `GET /assignment` агенту продолжает отдавать
+`204` (агент просто ждёт следующего опроса, доработок на его стороне не
+требуется); в дашборде на `/ips` такой адрес в это время помечен бейджем
+«прогрев FIP» вместо обычного статуса.
+
+Значение обязано оставлять запас внутри лизинга адреса:
+`fip_settle_seconds + self_check_timeout_seconds` должно быть **меньше**
+`orchestrator.lease_ttl_seconds` — иначе пауза плюс сам self-check не
+влезут в лизинг, адрес не успеет пройти self-check до истечения
+`lease_ttl_seconds` и будет вечно возвращаться в очередь через
+`sweepExpiredLeases`. Попытка задать такое значение отклоняется `400`, не
+обрезается молча.
+
 ## Частые проблемы и что с ними делать
 
 **Валидатор долго висит в `unreachable`.**
@@ -421,7 +452,12 @@ curl -s -X POST http://<control-api>:8080/api/v1/admin/ips/clear
 (`systemctl status validator-agent`, `journalctl -u validator-agent`).
 
 **Адрес не выходит из `awaiting_self_check` (статус не меняется вообще).**
-Self-check запрашивает внешние (вне облака) сервисы из
+Если это длится всего несколько секунд и на стенде настроена
+[пауза перед self-check](#пауза-перед-self-check-fip_settle_seconds)
+(`fip_settle_seconds`) — это ожидаемое поведение, не сбой: адрес
+сознательно придерживается, прежде чем агенту разрешат начать проверку.
+Проблема — если статус не меняется значительно дольше этой паузы. Тогда
+дело обычно в self-check: он запрашивает внешние (вне облака) сервисы из
 `self_check.ip_echo_urls` в конфиге валидатора (по умолчанию
 `api.ipify.org`, `ifconfig.me`) — если у ВМ-валидатора нет исходящего
 доступа в интернет к этим адресам, запрос не проходит вообще, и агент