FKITDEV-8354 — vuer-release PR #28 supervisor-config dedup (round-2 review)
Resolving Bence’s round-2 review on vuer-release PR #28 (MVM partner migration to the Gen2 lean format). Two “merge this with the supervisor config in the <repo> repository” comments: the vuer_css one was a pure byte-identical duplicate (deleted), the vuer_oss one is an intentional partner override (kept). Includes the reusable mechanism for how supervisor configs reach /etc/supervisor/conf.d/ in vuer-release component images.
PR identity — do not conflate with FKITDEV-8252
TechTeamer/vuer-releasePR #28 =feat(FKITDEV-8354): migrate mvm project(branchfeature/FKITDEV-8354, basemaster) — the MVM partner migration (vuer_build → vuer-release Gen2 lean format). This is DISTINCT from PR #31 =feat: ubi10(FKITDEV-8252, branchfeature/FKITDEV-8252-ubi10) — the UBI10 base-image work. Different ticket, different branch, different scope. See FKITDEV-8252.
For Agents
- Repo:
TechTeamer/vuer-release; PR #28; branchfeature/FKITDEV-8354; basemaster; reviewerbencelaszlo.- Local worktree:
/Users/levander/coding/facekom/vuer-release/.worktrees/FKITDEV-8354.- Round-1 review (2026-05-08) already resolved: janus version pins
1.4.1/cc0fdca8; restored supervisor-stdout plugin (commit07db225).- Round-2 (2026-06-15) = two new comments, both “merge this with the supervisor config in the
<repo>repository”.- State 2026-06-16: changes made LOCAL & UNSTAGED in the worktree only. NOT committed, NOT pushed. Reply to Bence drafted, NOT posted. User constraint: do not write anything to GitHub.
The two round-2 comments and their resolutions
| File | Comment | Resolution |
|---|---|---|
projects/mvm/components/vuer_css/supervisor_vuer_css_docker.conf | merge with vuer_css repo config | DELETED — byte-identical duplicate of the vuer_css repo copy. Also removed its COPY … /etc/supervisor/conf.d/ line from projects/mvm/components/vuer_css/Dockerfile. |
projects/mvm/components/vuer_oss/supervisor_vuer_oss_docker.conf | merge with vuer_oss repo config | KEPT — intentional partner override, NOT a duplicate. Merging would regress the round-1 decision. |
vuer_css — safe to delete (provably behavior-neutral)
The partner copy was byte-identical to the vuer_css repo’s supervisor_vuer_css_docker.conf, i.e. a pure duplicate. Removing the file + its Dockerfile COPY is safe because the base image’s install/configure-app.sh (lines 16-21) symlinks all $APP_HOME/supervisor*.conf from the extracted source package into /etc/supervisor/conf.d/, and supervisord.conf includes files = /etc/supervisor/conf.d/*.conf. With the redundant COPY gone, the resulting conf.d file set is identical (the source-package conf is symlinked in either way). Behavior-neutral.
vuer_oss — intentional override (the architectural finding)
Compared against the correct baseline
The right baseline is the vuer_oss repo’s MVM source branch
origin/chore/FKITDEV-8892-mvm-devel-update-2026-06-01(blobd6e7843) — NOT plaindevel. The partner config is a customization layered on the MVM branch, so diff against that branch.
| Aspect | vuer_oss repo (MVM branch, blob d6e7843) | vuer-release MVM copy |
|---|---|---|
| Logging | file-based (stdout_logfile=/var/log/…) | supervisor-stdout eventlistener (stdout_events_enabled=true, stdout_logfile=NONE) |
| Program count | 9 programs | 8 programs |
[program:vuer_oss_storage] (node storage.js) | present | omitted |
Source-verified from the worktree copy (projects/mvm/components/vuer_oss/supervisor_vuer_oss_docker.conf): 8 programs — nginx, redis, vuer_oss, vuer_integration_log, vuer_media, vuer_oss_convert, vuer_cron, vuer_background — every program block uses stdout_events_enabled=true + stdout_logfile=NONE, and there is no [program:vuer_oss_storage].
Why merging it back would be wrong:
- The eventlistener apparatus lives ONLY in vuer-release. The trio
supervisor_stdout.py+supervisor_stdout_eventlistener.conf+pip install supervisor-stdout(in the Dockerfile) exists only in vuer-release — it is not in the vuer_oss repo at any ref. It is the consumer of the supervisor-stdout plugin Bence asked to RESTORE in round 1 (commit07db225). Collapsing this config to the repo’s file-logging version (stdout_logfile=/var/log/…) would make that plugin a no-op and regress the round-1 decision. - Dropping
vuer_oss_storageis the consistent vuer-release convention. Every partner that carries a vuer_oss supervisor conf in vuer-release omits[program:vuer_oss_storage]: equilor, nusz, polgaribank-facekom, unicredit, unicredit-srb, mvm. So the omission is an intentional, repo-wide convention — not an MVM-specific accident.
Reusable mechanism — how supervisor configs reach conf.d in vuer-release
Two paths into
/etc/supervisor/conf.d/(last-write-wins by filename)In vuer-release component images a supervisor config lands in
/etc/supervisor/conf.d/via two paths:
install/configure-app.shsymlinks the source package’ssupervisor*.conf(the repo’s own conf, baked into the source package).- The partner component Dockerfile
COPYs a partner override on top — same filename ⇒ last-write-wins, the override shadows the symlinked repo conf.
supervisord.confthen includesfiles = /etc/supervisor/conf.d/*.conf.Decision rule: a partner override is a deletable duplicate only if byte-identical to the repo’s conf (then the
COPYis redundant — the symlink already provides it). Otherwise it is an intentional customization and must be kept. → vuer_css = duplicate (deleted); vuer_oss = customization (kept).
State of changes (this session)
Local only — nothing pushed
- Worktree:
/Users/levander/coding/facekom/vuer-release/.worktrees/FKITDEV-8354git status:M projects/mvm/components/vuer_css/Dockerfile,D projects/mvm/components/vuer_css/supervisor_vuer_css_docker.conf- vuer_oss conf left untouched (kept by design).
- Unstaged, NOT committed, NOT pushed. Reply to Bence on the vuer_oss thread drafted but NOT posted. User explicitly said: do not write anything to GitHub.
Round-1 recap (already resolved, 2026-05-08)
- janus version pins →
1.4.1/cc0fdca8. - Restored the supervisor-stdout plugin (commit
07db225) — this is the plugin the vuer_oss eventlistener config above depends on.
Related
- FKITDEV-8252 — the other vuer-release PR (#31,
feat: ubi10); separate ticket/branch — do not conflate - vuer_oss
- vuer_css
- release-process
- infrastructure