CLOUD-599 Rebuild a damaged provider config instead of exiting - #77
Draft
smintank wants to merge 29 commits into
Draft
CLOUD-599 Rebuild a damaged provider config instead of exiting#77smintank wants to merge 29 commits into
smintank wants to merge 29 commits into
Conversation
added 3 commits
September 5, 2026 00:05
A missing, empty or unparsable provider config used to stop the service with status 6 until someone fixed the file by hand. It is now rebuilt from the last known good copy kept in /var/lib, or from the packaged default plus the cloud host name taken from the provider directory. A provider added under a custom --name has no trustworthy source, so its config is left untouched and reported instead of being repointed at a host that does not exist. Config files are written atomically, and a non-empty broken file is kept as .broken-<timestamp>.
The daemon now starts its MQTT client first, publishes the broken-configuration state and re-reads the config every cycle instead of making cloud requests, so it recovers as soon as the file is restored. The unit condition matches the provider directory rather than a config glob, otherwise a missing config could never be healed, and check-certs.sh skips its ATECC fixup on an empty file instead of failing ExecStartPre. An empty or unreadable frpc.conf is removed at start so frpc stops restarting until the cloud sends a new one.
Coverage Report for CI Build 8Coverage increased (+0.09%) to 97.566%Details
Uncovered Changes
Coverage Regressions1 previously-covered line in 1 file lost coverage.
Coverage Stats
💛 - Coveralls |
added 26 commits
September 5, 2026 00:25
In the hold state the settings fall back to the packaged defaults, so the retained value would reach the cloud with the wrong client certificate key. The daemon subscribes once the hold ends.
paho runs on_message in the network loop thread, so an exception escaping the handler stops publishes and keepalives for the rest of the run.
The hold loop already restarts a stopped loop before publishing; without the same check the mainline status updates are lost once it dies.
AppSettings reads the provider config from PROVIDERS_CONF_DIR, so the fixture let the host decide config_error: where that file is damaged the hold tests spin in wait_for_usable_config instead of reporting a result.
paho holds MQTTMessage.topic as bytes and decodes it on read, so reading it to log a handler failure raised out of the guard that exists to keep the network loop alive.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Что происходит; кому и зачем нужно:
CLOUD-599 (инцидент CLOUD-592). После аварийной перезагрузки конфиг провайдера
/etc/wb-cloud-agent/providers/<провайдер>/wb-cloud-agent.confоказался пустым, агент падалсо статусом 6, и контроллер выпадал из облака до ручного вмешательства. Теперь агент чинит
такой файл сам.
Что поменялось для пользователей:
последнего рабочего конфига в
/var/lib/wb-cloud-agent/providers/<провайдер>/, затем изпоставляемого
/etc/wb-cloud-agent.confс адресом облака из имени каталога провайдера.--name, не переключается на угаданный адрес: файл остаётся как есть,агент не ходит в облако, пишет WARNING и «Broken configuration» в MQTT-контрол
status,и подхватывает файл сразу после восстановления. Так же он ведёт себя, если восстановленный
конфиг не удаётся записать — например, когда
/etcсмонтирован только для чтения.show-providersпоказывает такого провайдера как «Broken configuration», а не пропускает его.wb-cloud-agent.conf.broken-<дата>, все восстановления видныв
journalctl -u wb-cloud-agent@<провайдер>.frpc.confудаляется при старте, чтобы frpc не перезапускался по кругу.*.conf, иначе отсутствующийконфиг нельзя было бы восстановить;
check-certs.shпропускает правку ATECC на пустом файле.Как проверял/а:
Юнит-тесты на каждый сценарий восстановления (пустой файл, битый JSON, отсутствующий файл,
нечитаемый файл, недоступный для записи каталог,
--name-провайдер, здоровый конфигне переписывается) на
tmp_path.Полный прогон: black, isort, pylint 10.00/10, pytest — 236 тестов, покрытие 94.0%.
Проверено на тестовых контроллерах WB6/WB7/WB8 (сборка 1.8.3): пустой, битый и отсутствующий конфиг восстанавливаются на всех трёх, после восстановления в журнале остаются INFO-строки в настроенном формате; при удержании контрол
statusпоказывает «Broken configuration» уже через цикл и держит его все 150 с, сетевой цикл paho жив, запросов в облако нет.