Repository navigation
bug(deploy): update-node.yml publishes the SLM frontend but never renders that node's nginx site config #15649
Description
Activity
Already delivered by PR #15654 (merged
450ac0a3), which closed #15610.playbooks/update-node.ymlnow includesslm_managerwithtasks_from: nginx_site.yml, guarded on'autobot-slm-frontend' in deploy_roles— verified in base.This issue was filed while implementing #15610, correctly identifying that only two of the four entry points rendered the site config. Review of #15654 caught the same gap independently and fixed it in that PR rather than deferring, because it was not a tidy-up: the served path had moved to
currentand every already-provisioned node still had an nginx config namingdist/, soupdate-node.ymlwould have published a fully-verified bundle to a path nginx never opened — silently, because every check inside the publish task passes.All four entry points now both publish and render:
update-all-nodes.yml publishes=True renders_site=True update-node.yml publishes=True renders_site=True slm_manager/tasks/main.yml publishes=True renders_site=True provision-fleet-roles.yml publishes=True renders_site=TrueThe include uses
tasks_fromrather than a copied template task, for the reason the sibling call site already records: a second copy drifts.
Found while implementing #15610.
What
playbooks/update-node.ymlpublishes the SLM frontend to a target node (it includesroles/_shared/tasks/build_publish_slm_frontend.yml) and mapsautobot-slm-frontendto thenginxservice inrole_service_map, so the node it deploys to does serve that bundle. It never renders or re-renders any nginx site config.Of the four SLM-frontend entry points, only two put the site config on the host:
roles/slm_manager/tasks/main.ymltasks/nginx_site.yml)playbooks/update-all-nodes.ymlplaybooks/provision-fleet-roles.ymlplaybooks/update-node.ymlWhy it matters
Any change to the served path reaches an
update-node.ymltarget only when one of the other three plays next runs against it. #15610 is exactly such a change: the target publishes a new bundle ontocurrentwhile its nginx keeps opening whatever the last provision aimed it at. The deploy reports green and the UI does not move — the silent-staleness shape #1607 and #15462 both cost time on.The reason this is filed rather than fixed inside #15610:
update-node.ymldeploys to an arbitrary target node, and renderingroles/slm_manager/templates/autobot-slm.conf.j2there needs the whole slm_manager variable set. Rendering it with defaults on a host that is not the SLM manager would write a wrong config, which is a bigger outage than the staleness it fixes. It needs its own design pass.Acceptance criteria
update-node.ymltarget that servesautobot-slm-frontend, with evidence from the play, not assumptionrole_service_mapentry is corrected to say sorepo_tests/slm_frontend_atomic_publish_15610_test.py) is extended to assert whichever of the two conclusions holds, so it cannot regress silently